question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Possibly incorrect WARN on monospaced build width consistency - some marks have zero advance width definitions

See original GitHub issue

Glyphs source file -> static instance TTF font build with fontmake v2.2.1 pipeline. This is a weight axis monospaced typeface.

Observed behaviour

fontbakery raises a WARN level report that the combining marks *comb glyphs in our glyph set have inconsistent widths in a monospaced typeface.

The report is:

* WARN: Font is monospaced but 9 glyphs (3.91304347826087%) have a different width. You should check the widths of: ['uni0308', 'gravecomb', 'acutecomb', 'uni0302', 'uni030C', 'uni030A', 'tildecomb', 'uni0304', 'uni0327'] [code: mono-outliers]

and this appears to come from this block of the fontbakery source:

https://github.com/googlefonts/fontbakery/blob/42e872c92947569f5972a76bb52175e95666ed08/Lib/fontbakery/profiles/shared_conditions.py#L152-L173

I reviewed the Glyphs source files and the advance width for all of the reported glyphs is set at the expected value for the typeface (600).

Here is what I see in the binaries:

>>> for glyphname, metrics in glyph_metrics.items():
...     if metrics[0] != 600:
...         print(f"{glyphname}: {metrics}")
...
uni0308: (0, 140)
gravecomb: (0, 213)
acutecomb: (0, 213)
uni0302: (0, 146)
uni030C: (0, 146)
uni030A: (0, 190)
tildecomb: (0, 126)
uni0304: (0, 161)
uni0327: (0, 200)

And a visual of dieresiscomb:

2020-10-05_18-07-38

It looks like a subset of the marks (maybe all combining marks?) are compiled with a zero advance width value and should be excluded from this check.

Expected behaviour

This is not reported as a warning for monospaced typefaces if these metrics are valid.

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:6 (6 by maintainers)

github_iconTop GitHub Comments

3reactions
felipesanchescommented, Oct 22, 2020

I’ve just verified that indeed commit 42e872c92947569f5972a76bb52175e95666ed08 (as suggested by @kontur) fixed the problem last month and was included in the last two stable releases, 0.7.30 and 0.7.31

@chrissimpkins please update your fontbakery installation to benefit from the fix.

0reactions
chrissimpkinscommented, Oct 21, 2020

Can you please send me some of those files, @chrissimpkins?

Done! Thanks Felipe!

Read more comments on GitHub >

github_iconTop Results From Across the Web

Legacy marks have incorrect width in monospaced font - Glyphs
Hi all, I am trying to export a monospaced font where all the glyphs have a width of 600. I have set the...
Read more >
PANOSE font classification system Metrics Guide: pan2
This digit describes the appearance of the serifs used in a font design and groups them into one of fourteen general categories. Serif...
Read more >
CSS Fonts Module Level 4 - W3C
The sole criterion of a monospace font is that all glyphs have the same fixed width. This is often used to render samples...
Read more >
afdko - PyPI
The AFDKO is a set of tools for building OpenType font files from PostScript ... Zero the advance width of source glyphs with...
Read more >
Combining marks advance width - TypeDrawers
Sooo, when developing fonts with FontForge, I got used to desigining my combining marks on a width of an average letter.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found