Stick: Version 1.100 added #3481
Conversation
|
Includes small improvements related to vert typesetting, and hinting removed. |
aaronbell
added
- Ready for Review
II CJK
* Stick Version 1.100 taken from the upstream repo https://github.com/fontworks-fonts/Stick.git at commit fontworks-fonts/Stick@7872941.
aaronbell
force-pushed
the
gftools_packager_ofl_stick
branch
from
620ab68 to
f58ca0d
Compare
Fontbakery reportFontbakery version: 0.7.16 [2] Family checks🔥 FAIL: Do we have the latest version of FontBakery installed?
⚠ WARN: Is the command `ftxvalidator` (Apple Font Tool Suite) available?--- Rationale --- There's no reasonable (and legal) way to run the command `ftxvalidator` of the Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc. If Font Bakery is not running on an OSX machine, the machine running Font Bakery could access `ftxvalidator` on OSX, e.g. via ssh or a remote procedure call (rpc). There's an ssh example implementation at: https://github.com/googlefonts/fontbakery/blob/master/prebuilt/workarounds/ftxvalidator/ssh-implementation/ftxvalidator
[15] Stick-Regular.ttf🔥 FAIL: Check copyright namerecords match license file.
🔥 FAIL: License URL matches License text on name table?
🔥 FAIL: METADATA.pb font.name value should be same as the family name declared on the name table.
🔥 FAIL: METADATA.pb font.name field contains font name in right format?
🔥 FAIL: METADATA.pb font.full_name field contains font name in right format?
🔥 FAIL: METADATA.pb font.post_script_name field contains font name in right format?
🔥 FAIL: Check name table: FONT_FAMILY_NAME entries.--- Rationale --- Checks that the family name infered from the font filename matches the string at nameID 1 (NAMEID_FONT_FAMILY_NAME) if it conforms to RIBBI and otherwise checks that nameID 1 is the family name + the style name.
🔥 FAIL: Font enables smart dropout control in "prep" table instructions?--- Rationale ---
This setup is meant to ensure consistent rendering quality for fonts across all
devices (with different rendering/hinting capabilities).
Below is the snippet of instructions we expect to see in the fonts:
B8 01 FF PUSHW 0x01FF
85 SCANCTRL (unconditinally turn on
dropout control mode)
B0 04 PUSHB 0x04
8D SCANTYPE (enable smart dropout control)
"Smart dropout control" means activating rules 1, 2 and 5:
Rule 1: If a pixel's center falls within the glyph outline,
that pixel is turned on.
Rule 2: If a contour falls exactly on a pixel's center,
that pixel is turned on.
Rule 5: If a scan line between two adjacent pixel centers
(either vertical or horizontal) is intersected
by both an on-Transition contour and an off-Transition
contour and neither of the pixels was already turned on
by rules 1 and 2, turn on the pixel which is closer to
the midpoint between the on-Transition contour and
off-Transition contour. This is "Smart" dropout control.
For more detailed info (such as other rules not enabled in this snippet),
please refer to the TrueType Instruction Set documentation.
🔥 FAIL: Check if the vertical metrics of a family are similar to the same family hosted on Google Fonts.--- Rationale --- If the family already exists on Google Fonts, we need to ensure that the checked family's vertical metrics are similar. This check will test the following schema which was outlined in Fontbakery issue #1162 [1]: - The family should visually have the same vertical metrics as the Regular style hosted on Google Fonts. - If the family on Google Fonts has differing hhea and typo metrics, the family being checked should use the typo metrics for both the hhea and typo entries. - If the family on Google Fonts has use typo metrics not enabled and the family being checked has it enabled, the hhea and typo metrics should use the family on Google Fonts winAscent and winDescent values. - If the upms differ, the values must be scaled so the visual appearance is the same. [1] https://github.com/googlefonts/fontbakery/issues/1162
🔥 FAIL: Checking OS/2 Metrics match hhea Metrics.--- Rationale --- When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has released many fonts with vertical metrics that don't match in this way. When we fix this issue in these existing families, we will create a visible change in line/paragraph layout for either Windows or macOS users, which will upset some of them. But we have a duty to fix broken stuff, and inconsistent paragraph layout is unacceptably broken when it is possible to avoid it. If users complain and prefer the old broken version, they have the freedom to take care of their own situation.
⚠ WARN: Is the Grid-fitting and Scan-conversion Procedure ('gasp') table set to optimize rendering?--- Rationale --- Traditionally version 0 'gasp' tables were set so that font sizes below 8 ppem had no grid fitting but did have antialiasing. From 9-16 ppem, just grid fitting. And fonts above 17ppem had both antialiasing and grid fitting toggled on. The use of accelerated graphics cards and higher resolution screens make this approach obsolete. Microsoft's DirectWrite pushed this even further with much improved rendering built into the OS and apps. In this scenario it makes sense to simply toggle all 4 flags ON for all font sizes.
⚠ 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.
⚠ WARN: Check if each glyph has the recommended amount of contours.--- Rationale --- Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story. However, a quotedbl should have 2 contours, unless the font belongs to a display family. This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.
The following glyphs do not have the recommended number of contours: Glyph name: zero Contours detected: 1 Expected: 2 or 3 ⚠ WARN: 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.
⚠ WARN: 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).
Summary
Note: The following loglevels were omitted in this report:
|
|
LGTM Stick_QA.zip |
RosaWagner
added
-- Needs confirmation
RosaWagner
added
--- to_sandbox
and removed
-- Needs confirmation
RosaWagner
added
I Small Fix
2d0856d: [gftools-packager] Stick: Version 1.100 added