Different rendering on windows

[Philipp Sporrer]

Some fonts define a different ascent and descent value for windows.

Here is, for example, how capsize shows Tajawal's metrics on Windows vs. Mac:

Mac	Windows

I've run a script against all google fonts, and around 30% have different ascent or descent values for windows than for other operating systems.

To align fonts with their cap size reliably across operating systems, we have to take the Win Ascent and Descent numbers into account and use them instead of the "normal" HHead metrics on Windows systems.

This is not really an issue with capsize itself because capsize doesn't care where the user gets their font metrics from. If they provide the Windows metrics in browsers on Windows and the other metrics in all other operating systems, it works fine. It's just that probably a lot of people aren't aware of this.

Maybe we can add this to the FAQ section on the website? Additionally, we could extend the automatic font metrics detection logic on the site to use the windows metrics when being viewed on Windows. (The fontkit library only seems to provide the HHead numbers. I've had success with opentype.js to extract also the Win numbers.)

I'm happy to help on this if wanted/needed 🙋‍♂️.

[Michael Taranto]

Yeah i was super wary of the cross OS issues leading into this project. I was pleasantly surprised how consistent the results were, but must have just been operating in the 70% with my test cases 😆.

As you point out its tricky, given CSS does not allowing you to target different OS's, means users would have to construct different sets of styles and apply them conditionally at runtime.

Currently looking at rebuilding the site (more detail, usage examples, dark mode etc). So may add this to FAQs as part of that work.

[LukasBeh]

@michaeltaranto Please add this to the FAQ. I was so confused about my font not being properly aligned on Apple devices. It took me so many hours to figure this out.

I managed to fix the font metrics issue on Windows by editing the font file in FontForge. Obviously, this only works if you are willing to self-host the font.

Here are the steps I followed:

• Open the font file in FontForge
• Go to Element ‣ Font Info ‣ OS/2 ‣ Metrics and uncheck (if checked) the “Is Offset” box for both Win Ascent and Win Descent.
• Enter the same values as the HHead Ascent and HHead Descent for the Win Ascent and Win Descent, except remove the minus sign from the Win Descent value.
• Save the font file and test it on different platforms.

This worked for me and made the font look consistent on both Windows and Mac/iOS.

I hope this helps some people who are facing the same issue. 😊

[Michael Taranto]

Thanks writing this down. Probably more information for font authors than Capsize consumers though, Capsize is merely exposing what is there.

Possibly some validation script ideas here though, given you have identified the troublesome differences. So we could looks at surfacing a warning if the tables arent setup as desired. That said it would probably only make sense for the unpack package, as the metrics package is published statically.

🤔