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

Reply via email to