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

hmaesta commented 5 years ago

screen shot 2019-02-07 at 16 52 30

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 commented 5 years ago

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

• Keynote 8.3 • macOS 10.14.3

screenshot 2019-02-08 at 1 51 24 pm

rsms commented 5 years ago

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

rsms commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.

screen shot 2019-02-08 at 07 42 28

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 commented 5 years ago

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 commented 5 years ago

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) edge

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 commented 5 years ago

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 commented 5 years ago

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

m4rc1e commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

rsms commented 5 years ago

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 commented 5 years ago

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

@hmaesta what was the previous release you were using?

hmaesta commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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: https://github.com/rsms/inter/pull/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: