Differences between Win and HHead metrics cause the font to be rendered differently on Windows vs. iOS (or Mac I assume)

[tompazourek]

The Roboto font has different metrics for "Win Ascent", "Win Descent" comparing to it's "HHead Ascent", "HHead Descent" metrics.

This causes it to look different on Mac-style OS (I could only test on iOS), and on Windows.

Windows uses Win metrics (seems like unless the "Really use Typo metrics" is checked, which it isn't for Roboto), iOS (and I assume Mac as well) uses HHead metrics.

Take a look at this CodePen:

https://codepen.io/tompazourek/pen/NvLvJp?editors=1100

The inline element's content-area can be seen as the black background.

On Windows, the size is computed as (Win Ascent + Win Descent / UMP) Font size, which is (1946+512)/2048 400px, equal to 480.078125px. On the screenshot, you can see the background size is really 480px.

On iOS (and Mac I assume), the size is computed as (HHead Ascent + HHead Descent / UMP) Font size, which is (1900+500)/2048 400px, equal to 468.75px (937.5px on Retina). On the screenshot, you can see the background size is 940px (not sure why not 938px, probably some rounding somewhere). If it would be using the same metrics as Windows, the height would be 960px (2 * 480px because of Retina).

---

Anyway, due to those differences, the font is rendered differently on iOS and Windows. If the metrics were set the same (as most of the fonts I've seen on Google Fonts do), the font would be rendered more or less the same way on iOS and Windows (at least size-wise, not talking about subpixel rendering, etc.)

Those differences affect the size of the content area, and the position of the baseline, although only very slightly. The size of the font content area can be important in some line-height situations, or for the case of using background on inline elements (like in the CodePen above).

Is there some reason why the Win metrics are different to HHead metrics? Is it intentional? Is it something that can be fixed? I'm curious to hear more about this.

[daliusd]

I would like to hear more behind this as well. Linux/Windows situation.

[dudewad]

And, really importantly, is changing these values and re-exporting a terrible terrible idea or not?

[tompazourek]

Sadly, this issue isn't getting much attention from the maintainers of the repo.

Maybe if we mark the issue with thumbs up, it will be ranked higher?

[m4rc1e]

And, really importantly, is changing these values and re-exporting a terrible terrible idea or not?

AFAIK, the linespacing will change in Ms Office which will cause documents to reflow. The family is very popular (~40 billion requests) so it will break a tonne of docs.

I don't know why the metrics are different but there may be a reason for it.

[tompazourek]

AFAIK, the linespacing will change in Ms Office which will cause documents to reflow. The family is very popular (~40 billion requests) so it will break a tonne of docs.

But it might mean that it's already broken as it is right now -- meaning if you open the same MS Office document on Windows, and on Mac, you get different line spacing.

[m4rc1e]

but it may be worse to break people's existing docs.

[tompazourek]

If there is a change of character width, or some hinting change, won't those cause document reflows? I think this change is more about fixing something that's currently broken, which is different behaviour on different OSs. Someone has an office document that's using Roboto, and then they install a newer version of the font, and then they wonder why it's slightly different? I think it's perfectly understandable.

Besides that, I think it's quite likely that Roboto is used much more frequently on the web than it is in office documents. And here it's quite a serious issue that the line spacing and alignments are different depending on if you view the website on iOS or Windows. This inconsistency does break people's layouts as it is right now.

To me, if I am working on a website, and I know that a font behaves this differently on iOS and Windows, I will avoid using this font. Because Roboto behaves so differently depending on the OS, I don't think it's well-suited for web use. It's just a matter of time when someone will be dealing with an issue where something is not aligned correctly on one platform and is correct on the other, and Roboto will be to blame.

I believe it is a major flaw and it should be fixed, and I think the benefits of having this fixed will outweigh any possible breaking changes.

[m4rc1e]

I agree with you, It is a problem. However, there's a certain subset of folks who will go crazy when you 'fix' something because you've broken their layouts (millions of layouts). We had a situation where we 'fixed' some hinting and it got out of hand, https://github.com/google/roboto/issues/244. Quite frankly life is too short to deal with such commotion. People will often workaround the issues in fonts so you end up breaking their workarounds.

If we were to implement this fix, we'd need to test it across all platforms, browsers and apps to understand the full scale of the changes. We cannot simply change the values and push. It would take several days of work to understand the severity of this change.

[m4rc1e]

One possible reason for why the metrics are the way they are is because Roboto was commissioned to replace a font Google was using at the time. This meant they needed to inherit the metrics from the legacy font.

[tompazourek]

I understand that it is a difficult change to make at this point, and thanks for sharing the insight of why this might have happened. Was the font that Roboto intends to replace the Droid font?

The difference in Roboto's case is actually very small, only around 2.3% difference between the Win and HHead. That means a 1 px of difference if using font size of 43 px (or maybe half of that if we're counting with half a pixel being rounded up).

That means that the usual font sizes used in UIs (12-20 px) might not be affected.