New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[GX] Support 'gvar' table #258
Conversation
I’ll gladly accept this as my brithday present! (Which is today :) ). Awesome!!! |
👍 |
hey @brawer, this is great! thanks for your work. however, I just git-checkout your "gvar" branch and tried to decompile Skia.ttf (as found in my OSX 10.9 Fonts folder) using TTX. I got this error:
|
FYI, the version of Skia.ttf font says "8.0d1e1". |
@anthrotype, can you send me your version of Skia.ttf (or tell me where you got it from)? I wonder if there might be different versions of the font floating around. I've been using the following versions for development: $ md5 *.ttf |
MD5 (/Library/Fonts/Skia.ttf) = a1462aa84f0608d2bad5acde0f0dc618 |
I have 10.9.5 and also have that one:
$ md5 /Library/Fonts/Skia.ttf
MD5 (/Library/Fonts/Skia.ttf) = a1462aa84f0608d2bad5acde0f0dc618
|
@brawer I sent you the font as attachment to your [@]brawer.ch email |
Thank you! I was working with a version of Skia.ttf that has this name record: “Skia; 10.0d4e1; 2014-08-18” while yours seems to be from 2002. Very curious to find out what the difference is; I'll have a look tomorrow. |
|
1 similar comment
|
Apple confirms that the older Skia font actually has an invalid gvar table from the Euro glyph onwards. It originated when the Euro glyph was added and went undetected for a long time. |
|
|
2 similar comments
|
|
|
Thanks for checking! In that case, I'll leave the code unchanged; the recent version of Skia.ttf (10.0d4e1 of 2014-08-18) is working fine. |
Yes, it's correct that fontTools fails on an invalid "gvar" table :) So keep the code as is. |
|
|
|
|
In Python 2.6, there were no set literals like {1, 2, 3}. Also, unittest had no assertSetEqual() and assertListEqual() methods.
Also, implement an __eq__ method on GlyphVariation so we can verify whether the result of round-tripping actually equals the original input.
Python's unittest framework has deprecated assertEquals() in favor of assertEqual().
In Python 3.2, the unittest framework fails to recognize that (1, range(65535)) is the same as (1, range(65535)). In any othe Python version from 2.6 to 3.4, this works fine.
When compiling the set of shared coordinates, walk over glyphs in self.variations instead of retrieving them in glyph order. This addresses a code review comment: https://github.com/brawer/fonttools/commit/0f86c1c0d352d3513c8e0c4b2f153f84782a32af#commitcomment-11375190
Before this change, a rounding issue in fixedToFloat() would sometimes change 'gvar' coordinate values when round-tripping Skia.ttf through TTX. This change works around #286.
|
1 similar comment
|
After this change, MacOS Yosemite 10.3.3 renders the Oslash glyph of Skia.ttf with the exact same outline before and after round-tripping the font through TTX. Before this change, the outlines were slightly different after round-tripping through TTX. In my initial reading of the “gvar” specification, I had assumed that (0,0) entries had no significance. However, that is not how the current MacOS implementation interprets it.
|
|
|
|
Before this change, the compilePoints() routine would wrongly clear the most-significant bit of the lower byte in its binary output. An example glyph affected by this bug was “perthousand.oldstyle” in the version of Skia.ttf that Apple ships with MacOS X Yosemite 10.10.3. Although the broken code path was exercised in the unit tests, the length of the test input just happened to have the affected bit clear, which is why this bug did not get caught by the previous test cases.
|
unittest.TestCase.assertSetEqual() was added in Python 2.7, so we default to assertEqual() on Python 2.6.
|
This make the code easier to understand, especially since there is a diffence between numPointsInGlyph, numPointsInRun and numPointsInData. Also, we now pass numPointsInGlyph to compilePoints() to later enable an optimization where numPointsInData == numPointsInGlyph. However, this change does not yet make that optimization.
|
After this change, round-tripping through TTX shrinks the size of all our test fonts. Specifically, Skia.ttf shrinks from 478K to 473K, JamRegular.ttf from 113K to 107K, and BuffaloGalRegular from 67K to 61K.
|
After round-tripping through TTX, the font rendering of MacOS X 10.9.5 can display
Skia.ttf, BuffaloGalRegular.ttf and JamRegular.ttf just fine including glyph variations.
Screen shot: