Hi Behdad, Thank you for pointing that out. I am aware of that. I think it would be easy to take care of that.
The first three bytes being 0x1F, 0x8B and 0x08 is only the case with `gzip' wrapper compressed documents and NOT with `zlib' wrapper compressed data. Right? If that's the case, it'll be easy to take care of this outside FT_Gzip_Uncompress, I think. :) On Tue, Jun 11, 2019 at 1:34 AM Behdad Esfahbod <beh...@behdad.org> wrote: > Note that OT-SVG only allows gzip-wrapper compressed documents, not > zlib-wrapped. > > On Sat, Jun 8, 2019 at 1:57 AM Moazin Khatri <moazinkha...@gmail.com> > wrote: > >> Hi, >> >> In OpenType fonts, SVG documents can be either in plain text or gzip >> encoded. >> >> While writing the code to read these documents I looked for a function >> which could do gzip decoding inside FreeType. That's when I found >> `FT_Gzip_Uncompress'. Using it, I realized it didn't work as expected and >> returned errors. >> >> After using zlib in a separate program on the same data I figured out the >> problem. Zlib data can be encoded with both `gzip' and `zlib' encoded >> wrapper. AFAIK, by default, it looks for only `zlib' wrapper. The current >> call to `inflateInit2' is: >> >> 749| err = inflateInit2( &stream, MAX_WBITS ); >>> >>> >> `MAX_WBITS' is 15. Thus, it only looks for `zlib' wrapper and in case of >> gzip compressed SVGs, returns error when `inflate' is called. The fix is to >> replace it with: >> >> 749| err = inflateInit2( &stream, MAX_WBITS|32 ); >>> >>> >> This enables both `gzip' and `zlib' decoding with automatic header >> detection. Solving my problem. >> >> I am quoting the relevant section from zlib's manual for reference. Can >> be seen here <https://www.zlib.net/manual.html>: >> >> windowBits can also be greater than 15 for optional gzip decoding. Add 32 >>> to windowBits to enable zlib and gzip decoding with automatic header >>> detection, or add 16 to decode only the gzip format (the zlib format will >>> return a Z_DATA_ERROR). >> >> >> This solves it for me and I HOPE this won't cause cause any previous code >> relying on `FT_Gzip_Uncompress' to fail. Let me know if there are easy >> tests to check that. >> >> Let me know if this is the right change and can also be made in master >> later on, meaning I can rely on it. :) >> >> Moazin >> >> >> _______________________________________________ >> Freetype-devel mailing list >> Freetype-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/freetype-devel >> > > > -- > behdad > http://behdad.org/ >
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel