On Thursday, January 12, 2017 at 10:59:13 AM UTC-8, Ethan Estrada wrote: > Then, is this a bug or something that should be an optional argument on the > function like `#:ignore-initial-bytes #t`? I am not deeply familiar with the > DEFLATE file format, but this seems like bug since it doesn't inter-operate > with other implementations of zlib/zip/DEFLATE.
If it isn't quite compatible with other DEFLATE implementations, I'd say it is a bug... For reference, what I'm trying to do is take zTXt and iTXt data from a PNG file and uncompress/compress it. Whenever I do compression from Racket, pngfix complains that the data isn't quite right: iTXt SKP default 15 Z_BUF_ERROR 853 [truncated] zTXt SKP default 15 Z_BUF_ERROR 402 IDAT OK maximum 15 15 25411 1000938 This is why I started looking into the details of the compression in the first place... Now that I think about it, it's probably naive of me to simple add those two bytes and expect everything to actually be working as expected - while the data is decompressed as I expect, there might be some special cases inside zlib-flate that allow it to be decompressed anyway. I'm assuming the Z_BUF_ERROR is being reported because it's not as flexible and the structure of the data is missing some information like length (or something). Wild speculation, though. I actually have no idea what's wrong and I'm trying to make sense of something I barely understand. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
