Skip to content
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

Merged
merged 57 commits into from Jun 10, 2015
Merged

[GX] Support 'gvar' table #258

merged 57 commits into from Jun 10, 2015

Conversation

brawer
Copy link
Collaborator

@brawer brawer commented May 5, 2015

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:
screen shot 2015-05-05 at 4 59 21 pm

@twardoch
Copy link
Contributor

twardoch commented May 5, 2015

I’ll gladly accept this as my brithday present! (Which is today :) ). Awesome!!!

@anthrotype
Copy link
Member

👍

@anthrotype
Copy link
Member

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:

An error occurred during the decompilation of this table
Traceback (most recent call last):
   File "/Users/cosimolupo/Documents/Github/fonttools/Lib/fontTools/ttLib/__init__.py", line 396, in __getitem__
     table.decompile(data, self)
   File "/Users/cosimolupo/Documents/Github/fonttools/Lib/fontTools/ttLib/tables/_g_v_a_r.py", line 192, in decompile
     self.variations[glyphName] = self.decompileGlyph_(numPoints, sharedCoords, axisTags, gvarData)
   File "/Users/cosimolupo/Documents/Github/fonttools/Lib/fontTools/ttLib/tables/_g_v_a_r.py", line 261, in decompileGlyph_
     tuples.append(self.decompileTuple_(numPoints, sharedCoords, sharedPoints, axisTags, tuple, tupleData))
   File "/Users/cosimolupo/Documents/Github/fonttools/Lib/fontTools/ttLib/tables/_g_v_a_r.py", line 291, in decompileTuple_
     deltas_x, pos = GlyphVariation.decompileDeltas_(len(points), tupleData, pos)
   File "/Users/cosimolupo/Documents/Github/fonttools/Lib/fontTools/ttLib/tables/_g_v_a_r.py", line 704, in decompileDeltas_
     assert len(result) == numDeltas
 AssertionError

@anthrotype
Copy link
Member

FYI, the version of Skia.ttf font says "8.0d1e1".

@brawer
Copy link
Collaborator Author

brawer commented May 5, 2015

@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 (BuffaloGalRegular.ttf) = 078884cc97efd563212615296487c018
MD5 (JamRegular.ttf) = b19606c00c4be88894b3430e173a59c7
MD5 (Skia.ttf) = 13711112e6da2dda19bdeee76c52c91d

@anthrotype
Copy link
Member

MD5 (/Library/Fonts/Skia.ttf) = a1462aa84f0608d2bad5acde0f0dc618

@davelab6
Copy link
Contributor

davelab6 commented May 5, 2015 via email

@anthrotype
Copy link
Member

@brawer I sent you the font as attachment to your [@]brawer.ch email

@brawer
Copy link
Collaborator Author

brawer commented May 5, 2015

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.

@landscape-bot
Copy link

Code Health
Repository health increased by 0.96% when pulling fb778c4 on brawer:gvar into f5cbeea on behdad:master.

1 similar comment
@landscape-bot
Copy link

Code Health
Repository health increased by 0.96% when pulling fb778c4 on brawer:gvar into f5cbeea on behdad:master.

@twardoch
Copy link
Contributor

twardoch commented May 5, 2015

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.

@landscape-bot
Copy link

Code Health
Repository health increased by 0.99% when pulling 6d949db on brawer:gvar into f5cbeea on behdad:master.

@landscape-bot
Copy link

Code Health
Repository health increased by 0.99% when pulling 4c12d86 on brawer:gvar into 080f580 on behdad:master.

2 similar comments
@landscape-bot
Copy link

Code Health
Repository health increased by 0.99% when pulling 4c12d86 on brawer:gvar into 080f580 on behdad:master.

@landscape-bot
Copy link

Code Health
Repository health increased by 0.99% when pulling 4c12d86 on brawer:gvar into 080f580 on behdad:master.

@landscape-bot
Copy link

Code Health
Repository health increased by 2% when pulling 37d3943 on brawer:gvar into 080f580 on behdad:master.

@brawer
Copy link
Collaborator Author

brawer commented May 7, 2015

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.

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.

@twardoch
Copy link
Contributor

twardoch commented May 7, 2015

Yes, it's correct that fontTools fails on an invalid "gvar" table :) So keep the code as is.

@landscape-bot
Copy link

Code Health
Repository health increased by 1% when pulling 6841bdb on brawer:gvar into 080f580 on behdad:master.

@landscape-bot
Copy link

Code Health
Repository health increased by 1% when pulling a2e479a on brawer:gvar into c0eb703 on behdad:master.

@landscape-bot
Copy link

Code Health
Repository health increased by 1% when pulling 1e7af51 on brawer:gvar into c0eb703 on behdad:master.

@landscape-bot
Copy link

Code Health
Repository health increased by 1% when pulling cb2898c on brawer:gvar into c0eb703 on behdad:master.

brawer added 10 commits June 8, 2015 23:00
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.
@landscape-bot
Copy link

Code Health
Repository health increased by 1% when pulling 64d8411 on brawer:gvar into a09d96f on behdad:master.

1 similar comment
@landscape-bot
Copy link

Code Health
Repository health increased by 1% when pulling 64d8411 on brawer:gvar into a09d96f on behdad:master.

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.
@landscape-bot
Copy link

Code Health
Repository health increased by 1% when pulling 624b2b7 on brawer:gvar into a09d96f on behdad:master.

@landscape-bot
Copy link

Code Health
Repository health increased by 1% when pulling e39c295 on brawer:gvar into a09d96f on behdad:master.

@landscape-bot
Copy link

Code Health
Repository health increased by 1% when pulling 1d211ff on brawer:gvar into a09d96f on behdad:master.

@landscape-bot
Copy link

Code Health
Repository health increased by 1% when pulling 1426431 on brawer:gvar into a09d96f on behdad:master.

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.
@landscape-bot
Copy link

Code Health
Repository health increased by 1% when pulling f121b07 on brawer:gvar into a09d96f on behdad:master.

unittest.TestCase.assertSetEqual() was added in Python 2.7,
so we default to assertEqual() on Python 2.6.
@landscape-bot
Copy link

Code Health
Repository health increased by 1% when pulling ca6126e on brawer:gvar into a09d96f on behdad:master.

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.
@landscape-bot
Copy link

Code Health
Repository health increased by 1% when pulling 4bbc1f7 on brawer:gvar into a09d96f on behdad:master.

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.
@landscape-bot
Copy link

Code Health
Repository health increased by 1% when pulling 7f6d2af on brawer:gvar into a09d96f on behdad:master.

behdad added a commit that referenced this pull request Jun 10, 2015
[GX] Support 'gvar' table
@behdad behdad merged commit b50b6f2 into fonttools:master Jun 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants