How do I convert a ZGL file to XGL?

July 12, 2006 11:27 AM

How do I convert a .ZGL (compressed binary) file to a .XGL (uncompressed ASCII) file?
posted by Java_Man to Computers & Internet (14 answers total)

Uncompress it.
posted by majick at 11:34 AM on July 12, 2006

Response by poster: Unfortunately, the decompression algorithm has to specifically account for the compression algorithm used: are you sure that zlib can uncompress this type of file?
posted by Java_Man at 12:13 PM on July 12, 2006

Compress output file (to ZGL file)

If this option is enabled (checkmarked) then the final ASCII file will be compressed with ZLIB to create a .zgl compressed file. This will make the file much smaller in size.

link


anyway, any time you see a compressed extension with .z, or .gz, you can be fairly sure its either zip or gzip compression. unix 'file' should also tell you the compression format.
posted by devilsbrigade at 12:20 PM on July 12, 2006

Response by poster: I downloaded zlib, but it appears that zlib is only a library. So I tried decompressing the file with gzip (as it uses zlib as its underlying algorithm), but that didn't work. (It didn't like the file suffix: and if you change the suffix to 'gz', it complains that it's not in the right format.) Then I tried using the example code (minigzip) that ships with the zlib source to decompress it, but that does not work either. Is there any binary that will use the zlib library off the shelf? There is code inside the open source XGL Viewer that decompresses ZGL files, but I was hoping to not have to try to tease it out of there. Lastly, the 'file' command shows the .zgl files as 'data' (on Fedora Core 5). Thanks for the tip offs so far!
posted by Java_Man at 2:28 PM on July 12, 2006

Use 'unzip myfile.zgl'

Works on FreeBSD, at least.
posted by devilsbrigade at 3:46 PM on July 12, 2006

gunzip -c < somefile.zgl > somefile.xgl

That means the data comes in on stdin, gunzip will never see the filename and can't bitch about the extension. And note that the angle brackets are redirections, not placeholders telling you to substitute somefile.zgl... you really type in the < and >
posted by polyglot at 6:59 PM on July 12, 2006

The two most common zlib-based compressed formats are gzip format and zip format. It's fairly likely that any file made using zlib will be in one of those formats, and of them, zip is the one you'll see most often disguised as something else.

If you're using Windows, and you have a compressed file that you suspect might be a zip file in disguise: make a copy of it, change the file extension on the copy to .zip, and double-click it.

In the unix family, gunzip or zcat will uncompress gzip files, and unzip wil uncompress zip files.
posted by flabdablet at 7:10 PM on July 12, 2006

Best answer: If none of this works for you, it may be the case that the contents of a .ZGL file are made by using zlib's deflate() function on the data that would otherwise go to straight out to the corresponding .XGL, omitting file format headers (possibly even omitting the internal zlib header and adler32 checksum, if the format is *really* braindead) in which case you'll probably need to code something up.

I found a small C program here that does this kind of raw zlib compression from stdin to stdout; seems to me that if you used that as a base and changed all the calls to deflate() and related functions to their inflate() equivalents and tweaked a little here and there, you'd probably get a working raw decompressor.
posted by flabdablet at 8:16 PM on July 12, 2006

How come no one's asked him what the hell the files come out of?

Hey, JavaMan? What *is* a .ZGL file?
posted by baylink at 8:42 PM on July 12, 2006

Yep. Just downloaded xglviewer.zip and had a poke around in the import code, and all it seems to do with .zgl files is run them through inflate(); there's no header processing done. IIRC inflate() will actually autodetect and skip gzip headers if present, so it's a total pain that the .zgl files you have apparently don't include gzip wrappers. Designers who don't use standard formats to do standard jobs need a good kick up the arse.

Fortunately there's a reasonably easy workaround. If you whack a minimal gzip header onto the front of a bunch of raw zlib-compressed data and then pipe the result through zcat, you get uncompressed data out the other end of the pipe, with an easily-ignored complaint about an unexpected end-of-file when the gzip checksum trailer doesn't turn up as expected.

Procedure for Windows command prompt

Make the header file by using debug, as follows:

debug
e 100 1f 8b 08 00 00 00 00 00 00 ff
n gzheader
r cx
0a
w
q

To uncompress .zgl files:

copy /b gzheader+yourfile.zgl yourfile.xgl.gz
zcat yourfile.xgl.gz >yourfile.xgl
del yourfile.xgl.gz

A simple gunzip yourfile.xgl.gz won't work, because gunzip will barf on the missing checksum trailer.

Procedure for bash shell (unix family, or Cygwin under Windows)

To make the header file:

echo -ne '\037\213\010\0\0\0\0\0\0\377' >gzheader

To uncompress .zgl files:

cat gzheader yourfile.zgl | zcat >yourfile.xgl

I don't have any .zgl files available for testing, so please let me know whether this works!
posted by flabdablet at 10:14 PM on July 12, 2006

Looking over assorted zlib specs again: if what I just told you to do doesn't work, there might be extra header stuff in the front of the .zgl file that will confuse zcat. If you mail me one of your files (address is in my profile) I'd be happy to fiddle until I can uncompress it.
posted by flabdablet at 1:05 AM on July 13, 2006

Response by poster: Thanks, everyone for all of the responses! The ZGL files that I have been working with were exported from Solid Works. They are CAD files. More specifically, they are an export of the solid 3D CAD data into polygonal meshes, represented by OpenGL commands, wrapped in XML, and compressed with Zlib.

I tried the advice about adding the gzheader, but that did not work. Nor did any of the 'unzip' or 'gunzip' suggestions. The gzheader attempt resulted in this error: "zcat: stdin: invalid compressed data--format violated."

However, I did have success decompressing the files!

I followed flabdablet's advice about using the small C program . I had to change a few lines of code. Everywhere where there was a call to 'deflate' something, I swapped it with 'inflate'. The only catch was the line: "deflateInit(&z, compression_rate);"
That needs to be changed to "inflateInit(&z);" as inflateInit does not take a compression rate parameter. Also, be sure to compile it as C++ code (instead of C code) and add: "#include ".

Thanks again for the help!
posted by Java_Man at 9:40 AM on July 13, 2006

Response by poster: Oops. I forgot the character entity on that. You need to add the line: "#include <string.h>"

Thanks again.
posted by Java_Man at 9:44 AM on July 13, 2006

Response by poster: Oh, one other thing, anywhere where something was set to the input_buffer or output_buffer (e.g. line 79), I had to explicitly cast to Bytef*.

E.g. "z.next_out = output_buffer;" --> "z.next_out = (Bytef*)output_buffer;"
posted by Java_Man at 10:09 AM on July 13, 2006