-
Notifications
You must be signed in to change notification settings - Fork 11
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
review for PR of TN master #26
Conversation
note issue on conversion with too many alignment values
Fea compatibilize
accepted pull request of [wght].ttf build. noting outstanding git issue #2 question.
Thanks @pichotta, I'll take a look now. |
Fontbakery reportFontbakery version: 0.7.15 [4] Alegreya-Italic[wght].ttf🔥 FAIL: Font has old ttfautohint applied?--- Rationale --- This check finds which version of ttfautohint was used, by inspecting name table entries and then finds which version of ttfautohint is currently installed in the system.
🔥 FAIL: Are there caret positions declared for every ligature?--- Rationale --- All ligatures in a font must have corresponding caret (text cursor) positions defined in the GDEF table, otherwhise, users may experience issues with caret rendering.
🔥 FAIL: Is there kerning info for non-ligated sequences?--- Rationale --- Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg https://github.com/impallari/Raleway/issues/14).
⚠ WARN: Stricter unitsPerEm criteria for Google Fonts.--- Rationale --- Even though the OpenType spec allows unitsPerEm to be any value between 16 and 16384, the Google Fonts project aims at a narrower set of reasonable values. The spec suggests usage of powers of two in order to get some performance improvements on legacy renderers, so those values are acceptable. But value of 500 or 1000 are also acceptable, with the added benefit that it makes upm math easier for designers, while the performance hit of not using a power of two is most likely negligible nowadays. Another acceptable value is 2000. Since TT outlines are all integers (no floats), then instances in a VF suffer rounding compromises, and therefore a 1000 UPM is to small because it forces too many such compromises. Therefore 2000 is a good 'new VF standard', because 2000 is a simple 2x conversion from existing fonts drawn on a 1000 UPM, and anyone who knows what 10 units can do for 1000 UPM will know what 20 units does too. Additionally, values above 2048 would result in filesize increases with not much added benefit.
[4] Alegreya[wght].ttf🔥 FAIL: Font has old ttfautohint applied?--- Rationale --- This check finds which version of ttfautohint was used, by inspecting name table entries and then finds which version of ttfautohint is currently installed in the system.
🔥 FAIL: Are there caret positions declared for every ligature?--- Rationale --- All ligatures in a font must have corresponding caret (text cursor) positions defined in the GDEF table, otherwhise, users may experience issues with caret rendering.
🔥 FAIL: Is there kerning info for non-ligated sequences?--- Rationale --- Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg https://github.com/impallari/Raleway/issues/14).
⚠ WARN: Stricter unitsPerEm criteria for Google Fonts.--- Rationale --- Even though the OpenType spec allows unitsPerEm to be any value between 16 and 16384, the Google Fonts project aims at a narrower set of reasonable values. The spec suggests usage of powers of two in order to get some performance improvements on legacy renderers, so those values are acceptable. But value of 500 or 1000 are also acceptable, with the added benefit that it makes upm math easier for designers, while the performance hit of not using a power of two is most likely negligible nowadays. Another acceptable value is 2000. Since TT outlines are all integers (no floats), then instances in a VF suffer rounding compromises, and therefore a 1000 UPM is to small because it forces too many such compromises. Therefore 2000 is a good 'new VF standard', because 2000 is a simple 2x conversion from existing fonts drawn on a 1000 UPM, and anyone who knows what 10 units can do for 1000 UPM will know what 20 units does too. Additionally, values above 2048 would result in filesize increases with not much added benefit.
Summary
Note: The following loglevels were omitted in this report:
I'll look into the caret and lig fails later on today. Regressions Bracket layers missing on oslash/Oslash glyphs Double accents have collisions |
@m4rc1e Hmm, I'm not sure what the problem is with the /Oslash Currently the var font swaps /Oslash between Bold (has bar) and Extra Bold (has no bar). See screenshots attached. This seems to match the live Alegreya fonts on Google Fonts: Am I missing something? ############################## Regarding the double accents: I'll file a bug report for fontmake. In the mean time, it looks like we'll have to decompose all nested components |
Here's my fontmake bug report: |
…match in all masters
… and check diffenator
Fea next master
@m4rc1e |
Taken from the upstream repo https://github.com/huertatipografica/Alegreya at commit huertatipografica/Alegreya#26
@juandelperal |
Thanks @pichotta At a first glance I can see that:
Thanks |
This is awesome! When this PR is merged, will the Google Fonts API automatically provide the Variable font format for Alegraya? |
Update VF: build SC
@pichotta: The PR is merged! Will this be automatically now used by the Google Fonts API? |
@juandelperal |
Great! Thanks for fixing that. |
@m4rc1e
is this TN master branch ready for merge PR?