Line-height problem with regular compared to black (ATS bug)

[hmaesta]

Since I upgraded to Inter 3.3 there is a difference between line-height of Regular and Bold.

Environment

• OS: macOS 10.14.2
• Sketch 53 (72520)
• Inter 3.3

[vilav]

+1. Noticed the same.
Added Plex for comparison of bounding box spacing.

• Keynote 8.3
• macOS 10.14.3

[rsms]

So strange. What font files do you have installed? (Please be as detailed and exact as possible.)

[rsms]

Something's definitely not right here.
diffing fontinfo of regular and black otf yields some weird differences:

@fontinfo black vs regular

     "head": {
-      "checkSumAdjustment": 1882288472,
+      "checkSumAdjustment": 1637560464,
...
-      "xMax": 4860,
-      "xMin": -2433,
-      "yMax": 3145,
-      "yMin": -1196
+      "xMax": 4650,
+      "xMin": -2080,
+      "yMax": 3072,
+      "yMin": -1084
...
     "hhea": {
...
-      "xMaxExtent": 4860
+      "xMaxExtent": 4650

[rsms]

Here's what I'm seeing for OTF files of v3.2:

@ black vs regular (v3.2 OTF)
     "head": {
...
-      "xMax": 4860,
-      "xMin": -2433,
-      "yMax": 3145,
-      "yMin": -1236
+      "xMax": 4524,
+      "xMin": -2080,
+      "yMax": 3012,
+      "yMin": -1076
     },
     "hhea": {
...
-      "xMaxExtent": 4860
+      "xMaxExtent": 4524

The black, regular and light masters all have identical metrics in the source files, both Glyphs and UFO. The diff also shows that there are no differences between metrics that account for line-height, so this is really strange.

Additionally, it seems to only be an issue with ATS-based type rendering — the only way to reproduce this is with Apple software that directly uses ATS (i.e. no Safari.)

Adobe tools (uses adobe's type setter) as well as tools based on freetype and harfbuzz shows the correct line height.

[hmaesta]

What font files do you have installed?

I downloaded the latest release from inter/releases. (Here my installed fonts.)

---

Another example comparing all weights and line-heights.

Download Sketch file here.

You mentioned that on Adobe software it's correct (and in fact the line-height number is), but when creating a grid line and comparing the weights on Illustrator, Bold and Black have a slight difference between others. Could be a software bug though. (it's impossible to screenshot since Illustrator removes the "outer box" when hitting cmd – but you can download file here).

[thundernixon]

I can help look into this!

Typically, Google Fonts projects need to set custom parameters in GlyphsApp to control vertical metrics in their various flavors. This is one thing that FontBakery helps to catch. I’m on my phone right now, but I’ll be able to post more detail later.

[rsms]

This is what I'm seeing:

Apple TextEdit: (uses ATS/CoreText)

Sketch 53: (uses ATS/CoreText)

Illustrator CC 2019

Figma: (uses Freetype & Harfbuzz)

InVision Studio 1.8.4:

Adobe XD 15:

Adobe InDesign CC 14:

Google Chrome 72: (uses Freetype & Harfbuzz)

Apple Safari 12:

Microsoft Edge 42: (probably uses DirectWrite)

Microsoft WordPad: (Win 10; uses DirectWrite)

This is the data I'm getting from Freetype for Inter-Black.otf:

ascender: 2708
descender: -660
faceFlags: 537
faceIndex: 0
familyName: Inter
height: 3368
maxAdvanceHeight: 3368
maxAdvanceWidth: 4928
numCharmaps: 3
numFaces: 1
numFixedSizes: 0
numGlyphs: 2345
styleFlags: 0
styleName: Black
underlinePosition: -576
underlineThickness: 320
unitsPerEm: 2816

This is the data I'm getting from Freetype for Inter-Regular.otf:

ascender: 2708
descender: -660
faceFlags: 537
faceIndex: 0
familyName: Inter
height: 3368
maxAdvanceHeight: 3368
maxAdvanceWidth: 4928
numCharmaps: 3
numFaces: 1
numFixedSizes: 0
numGlyphs: 2345
styleFlags: 0
styleName: Regular
underlinePosition: -560
underlineThickness: 192
unitsPerEm: 2816

[rsms]

I tried scaling the glyphs source to 2048 UPM, compiled font files and tested with the Apple apps. No difference. So probably not a UPM-related bug (there has been issues with uncommon UPMs in ATS/CoreText.)

[emma-sg]

Seeing the same thing on Apple Pages/Numbers/Keynote, presumably they use ATS/CoreText as well

[m4rc1e]

I've had this issue before on Android. Some applications use the font's yMin and yMax to determine the position for the first line of text.

[rsms]

Diffing ttx:

(. init.sh ; ttx build/fonts/const/Inter-Regular.otf & ; ttx build/fonts/const/Inter-Black.otf & ; wait)
diff -u build/fonts/const/Inter-*.ttx

Notable differences: (Black vs Regular)

-    <underlinePosition value="-416"/>
+    <underlinePosition value="-464"/>

This is by design though and shouldn't affect line height.
There really is nothing else sticking out that affects height... What a mystery.

[m4rc1e]

I'm pretty sure Roboto experienced this issue in Android.

To solve it they forced the yMin and yMax using the following script, https://github.com/google/roboto/blob/master/scripts/force_yminmax.py

https://github.com/google/roboto/blob/master/Makefile#L39

[rsms]

@m4rc1e I patched the font files' yMin and yMax to match (otf -> ttx, patch values, ttx -> otf) and I get the same results.

[rsms]

Here are the highest and lowest glyphs in the regular and black masters: (from a script in Glyphs)

Master: Regular
   Highest: Adieresismacron (top y: 3072.0)
   Lowest: ydotbelow (bottom y: -1084.0)

Master: Black
   Highest: Idieresisacute (top y: 3146.0)
   Lowest: ydotbelow (bottom y: -1196.0)

(looks normal)

[m4rc1e]

Inter UI v3.2 seems to have the same issue.

@hmaesta what was the previous release you were using?

[hmaesta]

what was the previous release you were using?

Unfortunately I don't remember, but I don't believe it was 3.2 since I can't remember the last time I updated (so it must be a long time).

[m4rc1e]

@hmaesta thanks. I can confirm 2.2 was ok.

@rsms Apologies for the goose chase. I may take a look at this on Monday...the beer is calling. Nice font btw! the progress between different versions is really impressive.

[thundernixon]

This seems to still be an issue in v3.3, currently the latest release.

However, I (tentatively) think I may have resolved the issue (click image to see it bigger if the bounding boxes are too faint):

Pull Request with updates: #141

---

I have followed an earlier system suggested by @m4rc1e, using a script to apply custom parameters across all masters based on min and max heights, then rebuilding:

Sketch (Inter 3.4 WIP)

Variable

Static

TextEdit (Inter 3.4 WIP)

Variable

Static

[rsms]

Confirming build off of master fb79b9e works correctly and fixes the issues. Nice work @thundernixon !

ATS based apps:

Freetype/Harfbuzz:

Here's a build of master fb79b9e if you want to try yourself:
Inter-3.4-fb79b9ee89.zip