Updating STAT table in Reem-Kufi #3602
Conversation
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
[12] ReemKufi[wght].ttf🔥 FAIL: Does DESCRIPTION file mention when a family is available as variable font?--- Rationale --- Families with variable fonts do not always mention that in their descriptions. Therefore, this check ensures that a standard boilerplate sentence is present in the DESCRIPTION.en_us.html files for all those families which are available as variable fonts.
🔥 FAIL: Check copyright namerecords match license file.
🔥 FAIL: Copyright notices match canonical pattern in METADATA.pb
🔥 FAIL: Copyright notices match canonical pattern in fonts
🔥 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: A static fonts directory with at least two fonts must accompany variable fonts--- Rationale --- Variable font family directories kept in the google/fonts git repo must include a static/ subdir containing static fonts. These files are meant to be served for users that still lack support for variable fonts in their web browsers.
🔥 FAIL: Checking OS/2 usWinAscent & usWinDescent.--- Rationale --- A font's winAscent and winDescent values should be greater than the head table's yMax, abs(yMin) values. If they are less than these values, clipping can occur on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33). If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin).
🔥 FAIL: Are there unwanted tables?--- Rationale --- Some font editors store source data in their own SFNT tables, and these can sometimes sneak into final release files, which should only have OpenType spec tables.
They can be removed by using fonttools/ttx. 🔥 FAIL: Does the font have a DSIG table?--- Rationale --- Microsoft Office 2013 and below products expect fonts to have a digital signature declared in a DSIG table in order to implement OpenType features. The EOL date for Microsoft Office 2013 products is 4/11/2023. This issue does not impact Microsoft Office 2016 and above products. This checks verifies that this signature is available in the font. A fake signature is enough to address this issue. If needed, a dummy table can be added to the font with the `gftools fix-dsig` script available at https://github.com/googlefonts/gftools Reference: https://github.com/googlefonts/fontbakery/issues/1845
⚠ WARN: Description strings in the name table must not exceed 200 characters.--- Rationale --- An old FontLab version had a bug which caused it to store copyright notices in nameID 10 entries. In order to detect those and distinguish them from actual legitimate usage of this name table entry, we expect that such strings do not exceed a reasonable length of 200 chars. Longer strings are likely instances of the FontLab bug.
⚠ WARN: METADATA.pb: Fontfamily is listed on Google Fonts API?
⚠ 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:
|
|
FAILS here follow the previous version of the font. No changes except to the STAT table (and associated naming) were made to the file. |
It is just a Makefile that calls fontmake. |
|
Well, you yourself called it complicated when justifying not fixing the STAT table issues that were called out previously. I’m just following your lead :). Furthermore, from that thread, I didn’t get the sense that you would be open to my modifying your build process to correctly generate the STAT table, so felt it better left alone until fontmake generates the STAT table automatically. If that is not the case please let me know. Else this PR correct the issue as it currently stands. |
|
Fair enough. I’m open to modifications that does not require additional dependencies, basically if fontmake output is wrong fontmake should be fixed instead of patching every font project to work around it. |
|
Also I’m probably reluctant because it is not clear to me what are we fixing here, it seems like a workaround for a software bug and I’m generally not interested in these. |
|
@khaledhosny The core problem is that at current Yes, I realize that If you don't want to explicitly add
Either way, it'll ensure that GF has a valid font with a correct |
But the <STAT>
<Version value="0x00010001"/>
<DesignAxisRecordSize value="8"/>
<!-- DesignAxisCount=1 -->
<DesignAxisRecord>
<Axis index="0">
<AxisTag value="wght"/>
<AxisNameID value="256"/> <!-- Weight -->
<AxisOrdering value="0"/>
</Axis>
</DesignAxisRecord>
<!-- AxisValueCount=0 -->
<ElidedFallbackNameID value="2"/> <!-- Regular -->
</STAT>It contains an Axis Record which the spec indeed requires:
It does not contain any Axis Values, but the spec does not require them:
(emphasis mine) So the font is spec complaint as far as I can tell, but I'm happy to learn otherwise. |
|
OK, I overstepped in saying it is non-compliant by the letter of the document. However, your STAT still does not accommodate the spirit of the document, which is to say how the STAT table can be used:
There is no way for an application that attempts, like above, to dynamically generate instance names from the STAT table, to do so from your STAT table. The only record you have provided is "Regular", so everything becomes Regular:
This is not a workable situation. |
|
The information in the STAT table Axis Values will just duplicate what is in |
|
Feel free to do what you want in your own repository but for the purposes of the version on google fonts, the full axis instance values must be present in the STAT table to ensure consistent enumeration across applications. |
OK, literally speaking, you're right. Should isn't must. But I agree with @aaronbell, for my part, this is not what I perceive from the spirit of the specs. |
|
Maybe ping Peter Constable or request clarification of the spec in an MS typography issue? |
|
It would indeed be a good thing if someone well placed at Microsoft could give their opinion on this, because one of the first implementations of a use of the STAT table, Microsoft Office for Mac, clearly chose to interpret the "should" in question as a "must". I find that this is sufficient to merit clarification in the specs. |
|
Font Bakery version 0.7.16 was released in December 2019!!!
There's been 23 releases since then, with lots of bug fixes, new checks and changes in checking criteria. :-) I don't know why this font is being checked nowadays using such an old version of Font Bakery, but this should be the very first thing to address before looking at any other check result. Note: I also see that one of the check results is actually trying to ensure you use the latest version.
|
|
@felipesanches yeah it's strange. Other PRs are pulling the latest release, #3582 (comment). |
|
This one has been inserted manually since the gh action failed with the diff. We should arrange the gh action for the FB report to show even if there are issues with browserstack. |
|
I convinced myself to اعصر على نفسي لمونة and add axis value to STAT table and postScriptNameID to fvar instances. This is in Reem Kufi main branch now. |
|
Glad to read this! (hope it doesn't hurt too much!) But I would still be happy to read what @PeterConstable could comment on on this particular point of the OT specs (shouldn't the "should" be replaced by a "must", for clarification?). |
|
Thanks @khaledhosny!!! So I guess the next step is for @aaronbell to pull your latest upstream and check it with latest FB and hopefully PR to GF :) (I am not sure which account should be used, @PeterConstable or @PeterCon) |
|
@aaronbell since Khaled agreed on that, can you pull the lastest version upstream? so we don't have dangerous hotfixes here |
The "spirit" of what was intended by the spec was noted: to allow variable fonts to work better in existing applications (which are numerous) that don't understand an open-ended font family model. IOW, to avoid issues that could look very busted for users, such as named instances that were advertised not being available; or named instances appearing to be available but when selected resulting in text from a different instance; etc.
In a specific case, perhaps. But in the general case, no. It would have been harder and more prone to error to try to call out when it might not be needed. Some changes in the STAT spec in regard to requirements ("must") or recommendations ("should") might be warranted. I'm inclined to be cautious, though. It's five years since the scenarios and details that led to the current spec were fresh in mind, and I wouldn't want to impose requirements if there are valid scenarios in which that might not be needed. It's conceivable that someone might create a font to be used in a closed context in which Axis Value Tables weren't needed for correct support. For that situation, "should be reflected in an axis value table" rather than "must" seems appropriate. But then, for that scenario, was it necessary to require the STAT table at all? "A style attributes table is required in all variable fonts." Perhaps that could have been made a recommendation rather than requirement? I do know there are implementations that use the STAT table even for non-variable fonts, and even for purposes beyond the original design intent. If folk think the STAT spec should be changed, then please post feedback on the STAT page. |
|
On the "should" vs. "must" topic, @aaronbell also opened an issue in MS' typography-issues, and I've added comments there. |
|
Thanks all. I've updated the files here to the official release version from @khaledhosny's repro. Thanks so much for your willingness to be flexible on this! |
Fontbakery reportFontbakery version: 0.8.0 [1] Family checks⚠ 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/main/prebuilt/workarounds /ftxvalidator/ssh-implementation/ftxvalidator
[12] ReemKufi[wght].ttf🔥 FAIL: Checks METADATA.pb font.post_script_name matches postscript name declared on the name table.
🔥 FAIL: METADATA.pb font.full_name value matches fullname declared on the name table?
🔥 FAIL: METADATA.pb font.name and font.full_name fields match the values declared on the name table?
🔥 FAIL: Copyright field for this font on METADATA.pb matches all copyright notice entries on the name table ?
🔥 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: METADATA.pb: Designer is listed with the correct name on the Google Fonts catalog of designers?
🔥 FAIL: Ensure variable fonts include an avar table.--- Rationale --- Most variable fonts should include an avar table to correctly define axes progression rates. For example, a weight axis from 0% to 100% doesn't map directly to 100 to 1000, because a 10% progression from 0% may be too much to define the 200, while 90% may be too little to define the 900. If the progression rates of axes is linear, this check can be ignored. Fontmake will also skip adding an avar table if the progression rates are linear. However, we still recommend designers visually proof each instance is at the desired weight, width etc.
🔥 FAIL: Are there unwanted tables?--- Rationale --- Some font editors store source data in their own SFNT tables, and these can sometimes sneak into final release files, which should only have OpenType spec tables.
They can be removed with the gftools fix-unwanted-tables script. [code: unwanted-tables] 🔥 FAIL: Does the font have a DSIG table?--- Rationale --- Microsoft Office 2013 and below products expect fonts to have a digital signature declared in a DSIG table in order to implement OpenType features. The EOL date for Microsoft Office 2013 products is 4/11/2023. This issue does not impact Microsoft Office 2016 and above products. This checks verifies that this signature is available in the font. A fake signature is enough to address this issue. If needed, a dummy table can be added to the font with the `gftools fix-dsig` script available at https://github.com/googlefonts/gftools Reference: https://github.com/googlefonts/fontbakery/issues/1845
⚠ WARN: Description strings in the name table must not exceed 200 characters.--- Rationale --- An old FontLab version had a bug which caused it to store copyright notices in nameID 10 entries. In order to detect those and distinguish them from actual legitimate usage of this name table entry, we expect that such strings do not exceed a reasonable length of 200 chars. Longer strings are likely instances of the FontLab bug.
⚠ WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table.--- Rationale --- The OpenType 'meta' table originated at Apple. Microsoft added it to OT with just two DataMap records: - dlng: comma-separated ScriptLangTags that indicate which scripts, or languages and scripts, with possible variants, the font is designed for - slng: comma-separated ScriptLangTags that indicate which scripts, or languages and scripts, with possible variants, the font supports The slng structure is intended to describe which languages and scripts the font overall supports. For example, a Traditional Chinese font that also contains Latin characters, can indicate Hant,Latn, showing that it supports Hant, the Traditional Chinese variant of the Hani script, and it also supports the Latn script The dlng structure is far more interesting. A font may contain various glyphs, but only a particular subset of the glyphs may be truly "leading" in the design, while other glyphs may have been included for technical reasons. Such a Traditional Chinese font could only list Hant there, showing that it’s designed for Traditional Chinese, but the font would omit Latn, because the developers don’t think the font is really recommended for purely Latin-script use. The tags used in the structures can comprise just script, or also language and script. For example, if a font has Bulgarian Cyrillic alternates in the locl feature for the cyrl BGR OT languagesystem, it could also indicate in dlng explicitly that it supports bul-Cyrl. (Note that the scripts and languages in meta use the ISO language and script codes, not the OpenType ones). This check ensures that the font has the meta table containing the slng and dlng structures. All families in the Google Fonts collection should contain the 'meta' table. Windows 10 already uses it when deciding on which fonts to fall back to. The Google Fonts API and also other environments could use the data for smarter filtering. Most importantly, those entries should be added to the Noto fonts. In the font making process, some environments store this data in external files already. But the meta table provides a convenient way to store this inside the font file, so some tools may add the data, and unrelated tools may read this data. This makes the solution much more portable and universal.
⚠ WARN: Font contains '.notdef' as its first glyph?--- Rationale --- The OpenType specification v1.8.2 recommends that the first glyph is the '.notdef' glyph without a codepoint assigned and with a drawing. https://docs.microsoft.com/en-us/typography/opentype/spec /recom#glyph-0-the-notdef-glyph Pre-v1.8, it was recommended that fonts should also contain 'space', 'CR' and '.null' glyphs. This might have been relevant for MacOS 9 applications.
Summary
Note: The following loglevels were omitted in this report:
|
Fontbakery reportFontbakery version: 0.8.0 [1] Family checks⚠ 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/main/prebuilt/workarounds /ftxvalidator/ssh-implementation/ftxvalidator
[5] ReemKufi[wght].ttf🔥 FAIL: METADATA.pb: Designer is listed with the correct name on the Google Fonts catalog of designers?
🔥 FAIL: Ensure variable fonts include an avar table.--- Rationale --- Most variable fonts should include an avar table to correctly define axes progression rates. For example, a weight axis from 0% to 100% doesn't map directly to 100 to 1000, because a 10% progression from 0% may be too much to define the 200, while 90% may be too little to define the 900. If the progression rates of axes is linear, this check can be ignored. Fontmake will also skip adding an avar table if the progression rates are linear. However, we still recommend designers visually proof each instance is at the desired weight, width etc.
⚠ WARN: Description strings in the name table must not exceed 200 characters.--- Rationale --- An old FontLab version had a bug which caused it to store copyright notices in nameID 10 entries. In order to detect those and distinguish them from actual legitimate usage of this name table entry, we expect that such strings do not exceed a reasonable length of 200 chars. Longer strings are likely instances of the FontLab bug.
⚠ WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table.--- Rationale --- The OpenType 'meta' table originated at Apple. Microsoft added it to OT with just two DataMap records: - dlng: comma-separated ScriptLangTags that indicate which scripts, or languages and scripts, with possible variants, the font is designed for - slng: comma-separated ScriptLangTags that indicate which scripts, or languages and scripts, with possible variants, the font supports The slng structure is intended to describe which languages and scripts the font overall supports. For example, a Traditional Chinese font that also contains Latin characters, can indicate Hant,Latn, showing that it supports Hant, the Traditional Chinese variant of the Hani script, and it also supports the Latn script The dlng structure is far more interesting. A font may contain various glyphs, but only a particular subset of the glyphs may be truly "leading" in the design, while other glyphs may have been included for technical reasons. Such a Traditional Chinese font could only list Hant there, showing that it’s designed for Traditional Chinese, but the font would omit Latn, because the developers don’t think the font is really recommended for purely Latin-script use. The tags used in the structures can comprise just script, or also language and script. For example, if a font has Bulgarian Cyrillic alternates in the locl feature for the cyrl BGR OT languagesystem, it could also indicate in dlng explicitly that it supports bul-Cyrl. (Note that the scripts and languages in meta use the ISO language and script codes, not the OpenType ones). This check ensures that the font has the meta table containing the slng and dlng structures. All families in the Google Fonts collection should contain the 'meta' table. Windows 10 already uses it when deciding on which fonts to fall back to. The Google Fonts API and also other environments could use the data for smarter filtering. Most importantly, those entries should be added to the Noto fonts. In the font making process, some environments store this data in external files already. But the meta table provides a convenient way to store this inside the font file, so some tools may add the data, and unrelated tools may read this data. This makes the solution much more portable and universal.
⚠ WARN: Font contains '.notdef' as its first glyph?--- Rationale --- The OpenType specification v1.8.2 recommends that the first glyph is the '.notdef' glyph without a codepoint assigned and with a drawing. https://docs.microsoft.com/en-us/typography/opentype/spec /recom#glyph-0-the-notdef-glyph Pre-v1.8, it was recommended that fonts should also contain 'space', 'CR' and '.null' glyphs. This might have been relevant for MacOS 9 applications.
Summary
Note: The following loglevels were omitted in this report:
|
|
I see you removed the MVAR table, but it is a useful table to have and fontbakery shouldn’t be rejecting it. |
Yes, I know it is a useful table, but the current GF requirement is to strip it. I’m glad that they’ll be revisiting that check and may update it in the future. When they do so I’m sure it’ll be added to many fonts :) |
|
I usually ignore such unreasonable requirements. |
|
Rejecting MVAR and failing (as opposed to warning) if there is no 'avar'---both seem wrong. |
@PeterConstable, the check that used to reject MVAR was modified not to do so anymore. Failing on missing |
|
An 'avar' table isn't required for OT conformance, and might not be required for a given design, but it's harmless to add an 'avar' table that does nothing in that case. |
RosaWagner
added
I Small Fix
This is a straight replacement of the existing Spartan font in the GF repository to resolve STAT-table related issues.
The build process in the upstream repro is rather complex, so it seemed better to directly update the font in GF to resolve the issue. Version bumped to 1.001.