Preparing Gidole Regular and Gidoliyna for publication on Google Fonts

Open yanone opened this issue 10 months ago • 0 comments

Hi,

German here who grew up in Ethiopia (Addis Ababa) for nine years myself...

I’m commissioned to onboard Gidole to Google Fonts. Are you willing to put in work to make that happen or shall we fork the repository to do it ourselves? This looks like it’s not in active development any longer.

Apart from the SFD format being difficult (but not impossible) for us to produce according to our standards, a few glyphs need to be added to the Latin and Greek character sets to fulfill our requirements. (Actually only a complete Latin is required, but since the Greek is almost complete, might as well finish that)

For your interest, below is a list of fails that need to be addressed (expand the lists to see details). Ignore the check about the Cyrillic counterparts, as well as that one programming error.

Please let me know how to proceed. Forking and doing the work ourselves is no issue for us. Thank you.

FontBakery report

fontbakery version: 0.13.2.dev9+gf84ac84b.d20250131

Check results

[17] Gidole-Regular.ttf

💥 ERROR Are there any misaligned on-curve points? outline_alignment_miss

This check heuristically looks for on-curve points which are close to, but do not sit on, significant boundary coordinates. For example, a point which has a Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the baseline, here we also check for points near the x-height (but only for lowercase Latin letters), cap-height, ascender and descender Y coordinates.

Not all such misaligned curve points are a mistake, and sometimes the design may call for points in locations near the boundaries. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported misalignments.

Original proposal: https://github.com/fonttools/fontbakery/pull/3088

💥 ERROR
Failed with IndexError: list index out of range

  File "/Users/yanone/.pyenv/versions/3.11.1/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/fontbakery/checkrunner.py", line 222, in _run_check
    subresults = list(subresults)
                 ^^^^^^^^^^^^^^^^
  File "/Users/yanone/.pyenv/versions/3.11.1/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/fontbakery/checks/outline_alignment_miss.py", line 61, in check_outline_alignment_miss
    for node in p.asNodelist():
                ^^^^^^^^^^^^^^
  File "/Users/yanone/.pyenv/versions/3.11.1/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/beziers/path/__init__.py", line 150, in asNodelist
    nl = self.activeRepresentation.toNodelist()
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/yanone/.pyenv/versions/3.11.1/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/beziers/path/representations/Segment.py", line 23, in toNodelist
    first = self.segments[0][0]
            ~~~~~~~~~~~~~^^^

[code: failed-check]

🔥 FAIL Checking font version fields (head and name table). opentype/font_version

The OpenType specification provides for two fields which contain the version number of the font: fontRevision in the head table, and nameID 5 in the name table. If these fields do not match, different applications will report different version numbers for the font.

Original proposal: https://github.com/fonttools/fontbakery/issues/4829

🔥 FAIL
head version is "2.00999" while name version string (for platform 1, encoding 0) is "Version 2.1 ".
[code: mismatch]
🔥 FAIL
head version is "2.00999" while name version string (for platform 3, encoding 1) is "Version 2.1 ".
[code: mismatch]

🔥 FAIL Ensure the font supports case swapping for all its glyphs. case_mapping

Ensure that no glyph lacks its corresponding upper or lower counterpart (but only when unicode supports case-mapping).

Original proposal: https://github.com/googlefonts/fontbakery/issues/3230

🔥 FAIL
The following glyphs lack their case-swapping counterparts:

Glyph present in the font	Missing case-swapping counterpart
U+0412: CYRILLIC CAPITAL LETTER VE	U+0432: CYRILLIC SMALL LETTER VE
U+0413: CYRILLIC CAPITAL LETTER GHE	U+0433: CYRILLIC SMALL LETTER GHE
U+0418: CYRILLIC CAPITAL LETTER I	U+0438: CYRILLIC SMALL LETTER I
U+041C: CYRILLIC CAPITAL LETTER EM	U+043C: CYRILLIC SMALL LETTER EM
U+041D: CYRILLIC CAPITAL LETTER EN	U+043D: CYRILLIC SMALL LETTER EN
U+041F: CYRILLIC CAPITAL LETTER PE	U+043F: CYRILLIC SMALL LETTER PE
U+042F: CYRILLIC CAPITAL LETTER YA	U+044F: CYRILLIC SMALL LETTER YA
U+0437: CYRILLIC SMALL LETTER ZE	U+0417: CYRILLIC CAPITAL LETTER ZE
U+0443: CYRILLIC SMALL LETTER U	U+0423: CYRILLIC CAPITAL LETTER U
U+1E36: LATIN CAPITAL LETTER L WITH DOT BELOW	U+1E37: LATIN SMALL LETTER L WITH DOT BELOW

[code: missing-case-counterparts]

🔥 FAIL Checking OS/2 usWinAscent & usWinDescent. family/win_ascent_and_descent

A font's winAscent and winDescent values should be greater than or equal to 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 absolute yMin values 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 absolute yMin.

Original proposal: https://github.com/fonttools/fontbakery/issues/4829

🔥 FAIL
OS/2.usWinAscent value should be equal or greater than 1910, but got 1906 instead
[code: ascent]

🔥 FAIL Check that legacy accents aren't used in composite glyphs. legacy_accents

Legacy accents should not have anchors and should have positive width. They are often used independently of a letter, either as a placeholder for an expected combined mark+letter combination in MacOS, or separately. For instance, U+00B4 (ACUTE ACCENT) is often mistakenly used as an apostrophe, U+0060 (GRAVE ACCENT) is used in Markdown to notify code blocks, and ^ is used as an exponential operator in maths.

Original proposal: https://github.com/googlefonts/fontbakery/issues/4310

🔥 FAIL
Legacy accent "grave" is defined in GDEF as a mark (class 3).
[code: legacy-accents-gdef]
🔥 FAIL
Legacy accent "dieresis" is defined in GDEF as a mark (class 3).
[code: legacy-accents-gdef]
🔥 FAIL
Legacy accent "macron" is defined in GDEF as a mark (class 3).
[code: legacy-accents-gdef]
🔥 FAIL
Legacy accent "acute" is defined in GDEF as a mark (class 3).
[code: legacy-accents-gdef]
🔥 FAIL
Legacy accent "cedilla" is defined in GDEF as a mark (class 3).
[code: legacy-accents-gdef]
🔥 FAIL
Legacy accent "circumflex" is defined in GDEF as a mark (class 3).
[code: legacy-accents-gdef]
🔥 FAIL
Legacy accent "caron" is defined in GDEF as a mark (class 3).
[code: legacy-accents-gdef]
🔥 FAIL
Legacy accent "breve" is defined in GDEF as a mark (class 3).
[code: legacy-accents-gdef]
🔥 FAIL
Legacy accent "dotaccent" is defined in GDEF as a mark (class 3).
[code: legacy-accents-gdef]
🔥 FAIL
Legacy accent "ring" is defined in GDEF as a mark (class 3).
[code: legacy-accents-gdef]
🔥 FAIL
Legacy accent "ogonek" is defined in GDEF as a mark (class 3).
[code: legacy-accents-gdef]
🔥 FAIL
Legacy accent "tilde" is defined in GDEF as a mark (class 3).
[code: legacy-accents-gdef]
🔥 FAIL
Legacy accent "hungarumlaut" is defined in GDEF as a mark (class 3).
[code: legacy-accents-gdef]

🔥 FAIL Checking Vertical Metric Linegaps. linegaps

The LineGap value is a space added to the line height created by the union of the (typo/hhea)Ascender and (typo/hhea)Descender. It is handled differently according to the environment.

This leading value will be added above the text line in most desktop apps. It will be shared above and under in web browsers, and ignored in Windows if Use_Typo_Metrics is disabled.

For better linespacing consistency across platforms, (typo/hhea)LineGap values must be 0.

Original proposal: https://github.com/fonttools/fontbakery/issues/4133 See also: https://googlefonts.github.io/gf-guide/metrics.html

🔥 FAIL
OS/2 sTypoLineGap is not equal to 0.

Overridden: This check was originally a WARN but was overridden by the universal profile: For Google Fonts, all messages from this check are considered FAILs.

[code: OS/2]

🔥 FAIL Name table records must not have trailing spaces. name/trailing_spaces

This check ensures that no entries in the name table end in spaces; trailing spaces, particularly in font names, can be confusing to users. In most cases this can be fixed by removing trailing spaces from the metadata fields in the font editor.

Original proposal: https://github.com/fonttools/fontbakery/issues/2417

🔥 FAIL
Name table record with key = (1, 0, 0, 5) has trailing spaces that must be removed: 'Version 2.1 '
[code: trailing-space]
🔥 FAIL
Name table record with key = (3, 1, 1033, 5) has trailing spaces that must be removed: 'Version 2.1 '
[code: trailing-space]

🔥 FAIL Ensure glyphs do not have components which are themselves components. nested_components

There have been bugs rendering variable fonts with nested components. Additionally, some static fonts with nested components have been reported to have rendering and printing issues.

For more info, see:

https://github.com/fonttools/fontbakery/issues/2961

https://github.com/arrowtype/recursive/issues/412

Original proposal: https://github.com/fonttools/fontbakery/issues/2961

🔥 FAIL
The following glyphs have components which themselves are component glyphs:
Agrave
Aacute
Acircumflex
Egrave
Eacute
Ecircumflex
Igrave
Iacute
Icircumflex
Ograve and 133 more.

Use -F or --full-lists to disable shortening of long lists.

[code: found-nested-components]

🔥 FAIL Checking OS/2 Metrics match hhea Metrics. os2_metrics_match_hhea

OS/2 and hhea vertical metric values should match. This will produce the same linespacing on Mac, GNU+Linux and Windows.

Mac OS X uses the hhea values.

Windows uses OS/2 or Win, depending on the OS or fsSelection bit value.

When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Note that fixing this issue in a previously released font may cause reflow in user documents and unhappy users.

Original proposal: https://github.com/fonttools/fontbakery/issues/4829

🔥 FAIL
OS/2 sTypoAscender (1496) and hhea ascent (1860) must be equal.
[code: ascender]

🔥 FAIL Ensure smart dropout control is enabled in "prep" table instructions. smart_dropout

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.

Generally this occurs with unhinted fonts; if you are not using autohinting, use gftools-fix-nonhinting (or just gftools-fix-font) to fix this issue.

Original proposal: https://github.com/fonttools/fontbakery/issues/4829

🔥 FAIL
The 'prep' table does not contain TrueType instructions enabling smart dropout control. To fix, export the font with autohinting enabled, or run ttfautohint on the font, or run the gftools fix-nonhinting script.
[code: lacks-smart-dropout]

🔥 FAIL Are there unwanted Apple tables? unwanted_aat_tables

Apple's TrueType reference manual [1] describes SFNT tables not in the Microsoft OpenType specification [2] and these can sometimes sneak into final release files.

This check ensures fonts only have OpenType tables.

[1] https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6.html [2] https://docs.microsoft.com/en-us/typography/opentype/spec/

Original proposal: https://github.com/fonttools/fontbakery/pull/2190

🔥 FAIL
Unwanted AAT tables were found in the font and should be removed, either by fonttools/ttx or by editing them using the tool they're built with:

feat
morx
prop

[code: has-unwanted-tables]

🔥 FAIL Are there unwanted tables? unwanted_tables

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.

Original proposal: https://github.com/fonttools/fontbakery/issues/4829

🔥 FAIL
The following unwanted font tables were found:

FFTM - Table contains redundant FontForge timestamp info
prop - Table used on AAT, Apple's OS X specific technology. Although Harfbuzz now has optional AAT support, new fonts should not be using that.

They can be removed with the 'fix-unwanted-tables' script provided by gftools.

[code: unwanted-tables]

🔥 FAIL Copyright notices match canonical pattern in fonts googlefonts/font_copyright

This check aims at ensuring a uniform and legally accurate copyright statement on the name table entries and METADATA.pb files of font files across the Google Fonts library.

We also check that the copyright field in METADATA.pb matches the contents of the name table nameID 0 (Copyright), and that the copyright notice within the METADATA.pb file is not too long; if it is more than 500 characters, this may be an indication that either a full license or the font's description has been included in this field by mistake.

The expected pattern for the copyright string adheres to the following rules:

It must say "Copyright" followed by a 4 digit year (optionally followed by a hyphen and another 4 digit year)

Additional years or year ranges are also valid.

An optional comma can be placed here.

Then it must say "The Project Authors" and, within parentheses, a URL for a git repository must be provided. But we have an exception for the fonts from the Noto project, that simply have "google llc. all rights reserved" here.

The check is case insensitive and does not validate whether the familyname is correct, even though we'd obviously expect it to be.

Here is an example of a valid copyright string:

"Copyright 2017 The Archivo Black Project Authors (https://github.com/Omnibus-Type/ArchivoBlack)"

Original proposal: https://github.com/fonttools/fontbakery/pull/2383 See also: https://github.com/fonttools/fontbakery/issues/4829

🔥 FAIL
Name Table entry: Copyright notices should match a pattern similar to:

But instead we have got:

[code: bad-notice-format]

🔥 FAIL
Name Table entry: Copyright notices should match a pattern similar to:

But instead we have got:

[code: bad-notice-format]

🔥 FAIL Check license file has good copyright string. googlefonts/license/OFL_copyright

An OFL.txt file's first line should be the font copyright.

The expected pattern for the copyright string adheres to the following rules:

It must say "Copyright" followed by a 4 digit year (optionally followed by a hyphen and another 4 digit year)

Additional years or year ranges are also valid.

An optional comma can be placed here.

Then it must say "The Project Authors" and, within parentheses, a URL for a git repository must be provided. But we have an exception for the fonts from the Noto project, that simply have "google llc. all rights reserved" here.

The check is case insensitive and does not validate whether the familyname is correct, even though we'd obviously expect it to be.

Here is an example of a valid copyright string:

"Copyright 2017 The Archivo Black Project Authors (https://github.com/Omnibus-Type/ArchivoBlack)"

Original proposal: https://github.com/fonttools/fontbakery/issues/2764

🔥 FAIL
First line in license file is:

which does not match the expected format, similar to:

[code: bad-format]

🔥 FAIL Check copyright namerecords match license file. googlefonts/name/license

A known licensing description must be provided in the NameID 14 (LICENSE DESCRIPTION) entries of the name table.

The source of truth for this check (to determine which license is in use) is a file placed side-by-side to your font project including the licensing terms.

Depending on the chosen license, one of the following string snippets is expected to be found on the NameID 13 (LICENSE DESCRIPTION) entries of the name table:

"This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: openfontlicense.org"

"Licensed under the Apache License, Version 2.0"

"Licensed under the Ubuntu Font Licence 1.0."

Currently accepted licenses are Apache or Open Font License. For a small set of legacy families the Ubuntu Font License may be acceptable as well.

When in doubt, please choose OFL for new font projects.

Original proposal: https://github.com/fonttools/fontbakery/issues/4829

🔥 FAIL
License file LICENSE.txt exists but NameID 13 (LICENSE DESCRIPTION) value on platform 1 (MACINTOSH) is not specified for that. Value was: "Gidole is dual licensed under OFL (÷RFN) and MIT license - pick the one you prefer." Must be changed to "Licensed under the Apache License, Version 2.0"
[code: wrong]
🔥 FAIL
License file LICENSE.txt exists but NameID 13 (LICENSE DESCRIPTION) value on platform 3 (WINDOWS) is not specified for that. Value was: "Gidole is dual licensed under OFL (÷RFN) and MIT license - pick the one you prefer." Must be changed to "Licensed under the Apache License, Version 2.0"
[code: wrong]

🔥 FAIL Check Google Fonts glyph coverage. googlefonts/glyph_coverage

Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the GF-latin-core glyph-set.

Original proposal: https://github.com/fonttools/fontbakery/pull/2488

🔥 FAIL
Missing required codepoints:

- 0x0300 (COMBINING GRAVE ACCENT)


- 0x0301 (COMBINING ACUTE ACCENT)


- 0x0302 (COMBINING CIRCUMFLEX ACCENT)


- 0x0303 (COMBINING TILDE)


- 0x0304 (COMBINING MACRON)


- 0x0306 (COMBINING BREVE)


- 0x0307 (COMBINING DOT ABOVE)


- 0x0308 (COMBINING DIAERESIS)


- 0x030A (COMBINING RING ABOVE)


- 0x030B (COMBINING DOUBLE ACUTE ACCENT)


- 3 more.

Use -F or --full-lists to disable shortening of long lists.

[code: missing-codepoints]

🔥 FAIL Check font follows the Google Fonts vertical metric schema googlefonts/vertical_metrics

This check generally enforces Google Fonts’ vertical metrics specifications. In particular:

lineGap must be 0

Sum of hhea ascender + abs(descender) + linegap must be between 120% and 200% of UPM

Warning if sum is over 150% of UPM

The threshold levels 150% (WARN) and 200% (FAIL) are somewhat arbitrarily chosen and may hint at a glaring mistake in the metrics calculations or UPM settings.

Our documentation includes further information: https://github.com/googlefonts/gf-docs/tree/main/VerticalMetrics

Original proposal: https://github.com/fonttools/fontbakery/pull/3762 See also: https://github.com/fonttools/fontbakery/pull/3921

🔥 FAIL
OS/2.sTypoLineGap is "102" it should be 0
[code: bad-OS/2.sTypoLineGap]
🔥 FAIL
The sum of hhea.ascender + abs(hhea.descender) + hhea.lineGap is 2320 when it should be at least 2457
[code: bad-hhea-range]

[1] Family checks

🔥 FAIL OS/2.fsSelection bit 7 (USE_TYPO_METRICS) is set in all fonts. googlefonts/use_typo_metrics

All fonts on the Google Fonts collection should have OS/2.fsSelection bit 7 (USE_TYPO_METRICS) set. This requirement is part of the vertical metrics scheme established as a Google Fonts policy aiming at a common ground supported by all major font rendering environments.

For more details, read: https://github.com/googlefonts/gf-docs/blob/main/VerticalMetrics/README.md

Below is the portion of that document that is most relevant to this check:

Use_Typo_Metrics must be enabled. This will force MS Applications to use the OS/2 Typo values instead of the Win values. By doing this, we can freely set the Win values to avoid clipping and control the line height with the typo values. It has the added benefit of future line height compatibility. When a new script is added, we simply change the Win values to the new yMin and yMax, without needing to worry if the line height have changed.

Original proposal: https://github.com/fonttools/fontbakery/issues/3241

🔥 FAIL
OS/2.fsSelection bit 7 (USE_TYPO_METRICS) wasNOT set in the following fonts: ['GidoleFont/Gidole-Regular.ttf'].
[code: missing-os2-fsselection-bit7]

Summary

💥 ERROR	☠ FATAL	🔥 FAIL	⚠️ WARN	⏩ SKIP	ℹ️ INFO	✅ PASS	🔎 DEBUG
1	0	17	20	110	8	80	0
0%	0%	7%	8%	47%	3%	34%	0%

Note: The following loglevels were omitted in this report:

WARN
SKIP
INFO
PASS
DEBUG

Feb 04 '25 16:02 yanone