googlefonts / googlefonts/ufo2ft

CFF2 Variable font with unsusual UPM vertical metrics different/broken in Mac OS

Open
#368 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
176
Forks
48
PR merge metrics
No merged PRs in 30d

Description

Hey,

I've created a [test case](https://www.dropbox.com/s/zhs7z5u0ix7y5pp/Testfont-VF-CFF2.zip?dl=0) for a .glyphs source with two masters and a single letter `H`. The UPM is **3000**.

Fonts have been generated with fontmake:
```
fontmake -g Testfont.glyphs -o variable --output-path Testfont.ttf
fontmake -g Testfont.glyphs -o variable-cff2 --output-path Testfont.otf
```

Using fontmake to extract UFOs and reviewing them, the sources seem extracted correctly and _match_ the glyphs file. Inspecting the generated font's `OS/2` and `hhea` tables they appear to have _identical_ values.

Yet, the generated OTF and TTF files differ significantly in how they are rendered. Mac OS does not seem to deal well with the generated OTF files, e.g. OS font preview:

TTF selected in Finder:
Screenshot 2020-03-09 at 14 18 53

OTF selected (note the 1 pixel speck where the H in the font is located — for an actual production font with UPM 2100 and a full alphabet the entire font is previewed as little one-pixel specks — if this is a cropped cut off or if the entire glyph is scaled to be displayed as 1px I cannot tell):
![Screenshot 2020-03-09 at 14 18 57](https://user-images.githubusercontent.com/1893577/76213542-93b16a80-6213-11ea-8c15-78030c463b1d.jpg)

Comparison for an actual font:
TTF variable font preview:
Screenshot 2020-03-09 at 14 37 49
OFT variable font preview:
Screenshot 2020-03-09 at 14 37 46

The fonts looks similar in most programs and their cut off and vertical metrics behave like I'd expect, e.g. Adobe CC, or see below a screenshot of both files in Fontgoggles:
Screenshot 2020-03-09 at 14 25 41-fg

However, for example in Drawbot (which I believe uses the CoreText python bindings) the files appear equally cut off/cropped as in the Mac OS preview. Switching the font UPM to something more conventional like 1000 there no longer is this grave difference in _rendered_ the vertical metrics/cutoff.

Happy to test more to help narrow this down.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the linked Testfont.glyphs case and reproduce the generated variable-cff2 and variable TTF outputs using the shown fontmake commands. Compare their OS/2 and hhea tables, then check rendering in macOS Preview and Drawbot; the issue is done when the cause of the different vertical metrics is identified and the OTF renders consistently.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.