Accents below lowercase letters can be more compact

[thundernixon]

Describe the bug

While looking into vertical metrics standards for Google Fonts, I realized that my recent PR to Inter was probably not optimal: it's default line height is significantly higher than most comparable fonts.

The root cause of this is that the script I set the vertical metrics with. It sets the winDescent to the lowest y-coordinate in the font. Meanwhile, winAscent is the highest y-coordinate in the font (Å). This helps avoid clashes between lines of text, because winDescent and winAscent are used for the total default line height.

Actually, the MS OpenType spec says:

Some legacy applications use the usWinAscent and usWinDescent values to determine default line spacing. This is strongly discouraged. The sTypo* fields should be used for this purpose.

...but these still seem to be the values used in Sketch & TextEdit. I need to do a bit more research to compare vertical metric values in fonts similar to Inter to know for sure.

However, I believe the design suggestions in this issue are valid, either way.

In Inter, the /ydotbelow glyph has a dot below its descender. This is logical, but seemingly not typical – many other fonts put it to the right of the y. In the case of Inter, it means that the TypoDescender is quite low, and as a result, the default line height is abnormally large.

Here are several fonts set at their default line heights, in Sketch:

And one with Inter's line height reduced:

Expected behavior

I propose two changes:

1. The ydotbelow dot is moved up and to the right, as in comparable fonts
2. The commaaccentbelow is made slightly more compact (less critical, but still useful). It is the second-lowest object in the font, and significantly bigger than commaaccents from related designs.

Environment

• OS: macOS 10.14, Core Text
• App that renders the font: Sketch, TextEdit, etc
• Version of font: Version 3.004;git-8321f7c65

Additional context
I wanted to note down my research in an issue, and (unless something big comes up) I'll change these things tomorrow, adjust the vertical metrics again, and submit another PR. Vertical metrics are some of the more important things to really get right before we publish to Google Fonts, because it will obviously make a very big difference to people's layouts if these change after the font is implemented in websites, etc.

[thundernixon]

This might be an obvious thing, but I wanted to check anyway ... web browsers Chrome, Safari, and Firefox (on Mac) have the same default line-height as appears in TextEdit/Sketch, if no explicit value is set:

[rsms]

Agreed! I can see if I can fix this tonight.

[thundernixon]

@rsms at the risk of pointing out what may already be obvious, depending on your github notification setup & habits, I've given a start and more information in the PR #146.

[rsms]

Closed by e1d8712

[thundernixon]

Having checked the latest version, it's looking better! However, I vote that we make one more iteration of this.

The remaining problem

In the latest version, the winDescent–winAscent "bounding box" of the font is set too high, in my opinion. winAscent is higher than the tallest common glyph (Å) and winDescent isn't quite as low as a common descender (y).

A small problem is that in certain software, this may partially cutoff the bottom curve of the /y glyph.

The bigger problem is when a user tries to use the font for interface design in Sketch – say, to mockup a button. If they vertically-center a textbox of Inter with a button shape, the text will look substantially below-center. In a font like SF, it looks much more vertically-centered, by default. (Honestly, SF isn't perfect for this, but it's pretty close – and there's no reason Inter shouldn't be nicer to use for interface design 🙂).

This is also a problem for users trying to use Inter in other Mac apps – say, to make a presentation in Keynote. Here's Inter vs SF, with center vertical alignment in Keynote:

This alignment will probably annoy the heck out of obsessive designers like myself. 😄

But what about in an actual web browser?

I made a quick codepen to take a look at how things are working in an actual web browser: https://codepen.io/thundernixon/pen/RONBKV

Here, it looks like the typo metrics are being properly respected, and this puts both fonts nicely in the vertical center, without issue:

So, should we change the winDescent–winAscent values?

I vote "yes." Even if it works well in a browser, a lot of interface design happens within desktop Mac tools, so we should make it work really well, there. If we don't, designers will probably waste time trying to align the fonts as they want, and then they'll waste the time of their developer teammates by specifying that all button text should be nudged up by 1.5px, etc etc.

I'll make a PR with these values as I think makes sense, and we can discuss further, there.

[thundernixon]

Update: yessss I think I actually properly nailed down a solution that tests well on multiple tricky fronts, after some trial-and-error. Will PR later tonight!

[rsms]

Just released v3.5 containing these recent changes.