RE: Transformed ‘glyf’ table getting larger than the original

Hi Khaled,

I wouldn't say it's normal but I suspect it is a possible corner case if the original glyph contour has a regularly spaced sequence of points where _many_ points could have been binary-encoded using repeatable flags/delta coordinate values - the transformed glyph table would then include all of the repeated / skipped coordinate points into a data stream where each entry is at least two bytes long.

Thanks,
Vlad


-----Original Message-----
From: Khaled Hosny [mailto:khaledhosny@eglug.org] 
Sent: Monday, August 15, 2016 5:36 AM
To: WebFonts WG
Subject: Transformed ‘glyf’ table getting larger than the original

Is it normal that the transformed ‘glyf’ table (before compression) being
(much) larger than the original?

In SFNT-TTF.ttf[1] from the test suit, the original ‘glyf’ table is
712 bytes but the transformed table is 3706 bytes before compression, i.e. more than 5 times the original size. I wasn’t expecting the transformed tables to grow in size, let alone grow that much. I tested with several implementations (mine, Google’s and FontTools) and all give the same result. The only unusual aspect of that font is having a glyph with a single contour containing 506 points (it was constructed that way for the mustAccept255UInt16 test).

I’m just checking whether this is expected or not and what is the table should be transformed or not in this case.

Regards,
Khaled

1. https://github.com/w3c/woff2-tests/blob/master/generators/resources/SFNT-TTF.ttf

2. https://www.w3.org/Fonts/WG/wiki/TestPlan20-UserAgent#mustAccept255UInt16

Received on Tuesday, 30 August 2016 16:06:11 UTC