Preparing Gidole Regular and Gidoliyna for publication on Google Fonts

[yanone]

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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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
(RedHatOfficial/Overpass#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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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:

• Check for nested components fonttools/fontbakery#2961
• Printing issues due to running TTF fonts through a PostScript 3 printer arrowtype/recursive#412

Original proposal: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#2383
See also: fonttools/fontbakery#4829

• 🔥 FAIL

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

"Copyright 2020 The Familyname Project Authors (git url)"

But instead we have got:

"Copyright (c) 2015, Andreas Larsen @larsenwork"

[code: bad-notice-format]

• 🔥 FAIL

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

"Copyright 2020 The Familyname Project Authors (git url)"

But instead we have got:

"Copyright (c) 2015, Andreas Larsen @larsenwork"

[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: fonttools/fontbakery#2764

• 🔥 FAIL

  First line in license file is:

"copyright (c) 2015, andreas larsen @andreaslarsendk"

which does not match the expected format, similar to:

"Copyright 2022 The Familyname Project Authors (git url)"

[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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#3762
See also: fonttools/fontbakery#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: fonttools/fontbakery#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