Font top variations between Home windows and Mac
November 10, 2019
What’s the matter?
Look, I didn’t ask to be right here, however but once more I’ve gone down a rabbit gap of bizarre issues working programs do to fonts, and I don’t need anybody else to must spend 4 hours making an attempt to resolve this, so right here we’re. Beforehand, I wrote about the prepare wreck that’s making an attempt to make use of customized fonts with ggplot on Home windows. In the present day I’m again with one other story that can have you ever elevating your fist to the sky and screaming “Why is there no common specification for font rendering!?!?!?” However this time we’re transferring out of Rstudio and into the World Large Net, with a narrative about how font top and alignment varies between working programs and net browsers, and easy methods to repair all these issues.
Being a developer who makes use of each Mac and Home windows causes me fairly a little bit of ache, however on the brilliant facet, it additionally exposes points that I could by no means have recognized of if I had been simply blithely strolling down the trail of Mac happiness. For instance, at the moment I switched again over to my Home windows machine after an extended sabbatical on my Mac, and I seen that the drop-caps on my web site had been misaligned. Particularly, they had been about 10 pixels too excessive, in order that they caught out above the highest of the paragraph.
I knew virtually instantly that this needed to be a Home windows-specific bug. These drop-caps contain two separate glyphs to get the two-tone foreground and background, and the CSS was one of many trickiest components of my web site to drag off, so I’ve most likely spent extra time tweaking and troubleshooting and testing these drop-caps than anything on my website, which suggests there was no means it was one thing foolish I missed.
The answer
After studying by a couple of stackoverflow threads, I made a decision the issue could be within the vertical metrics of my font recordsdata. To know what this implies, let’s discuss a bit bit about how fonts are measured. The primary idea is the “em sq.”, that is merely a field which has a width and top of 1em, what’s an em? Easy, 1em equals the purpose measurement of the font, so for a font at 24 pixels, the em sq. is 24×24 pixels massive. The baseline is the underside of the place we begin drawing glyphs, and lies on the backside of the em sq.. The ascent is the space from the baseline to the highest of the tallest glyph, so usually 1em. The descent is the space from the baseline to the bottom level in any glyph. The descent may be totally different as a result of on net fonts, glyphs like g or p can have tails that stretch beneath the baseline.
So, what does this must do with our downside? Effectively, Home windows and Mac every have their very own specification for the ascent and descent values. On a Mac, a font appears for the ascent and descent in one thing known as the HHead desk, whereas on Home windows, a font appears for these values within the Win desk. Maybe you’ve guessed by now, that these tables can have totally different values for the ascent/descent of the identical font, resulting in totally different vertical alignment on Home windows and Mac machines.
The stackoverflow threads all recommended use of fontsquirrel, which is a free font generator to automagically repair these issues. Sadly, this didn’t work for me, as fontsquirrel solely lets you edit open-source fonts, and I used to be utilizing industrial fonts (I additionally discover their instrument steadily bugs out and simply refuses to work). So, I turned to the subsequent answer, manually enhancing the vertical metrics tables utilizing FontForge. FontForge is an open-source font enhancing software program, and it was pretty simple to do what I wanted. I opened my font file (it doesn’t matter what format), then went to Metrics > New metrics window, within the metrics window, choose Component > Font information..., this opens a brand new window, the place you’ll be able to navigate to OS/2 > Metrics. Right here you will notice the values for Win Ascent, Win Descent, HHead Ascent, and HHead Descent. In my case, Win Descent was totally different from HHead Descent, so I modified Win Descent to match the opposite values. Once you’re carried out enhancing, you’ll be able to return to the principle window, go to File > Generate fonts and export your edited font as WOFF, WOFF2, TTF, or no matter you want.
Bonus bugfix
Modifying the Win Descent within the font recordsdata fastened my Home windows downside, and I seen it additionally modified how the font rendered on Android gadgets. Beforehand, I had seen that on chrome on my cell gadget (however not in chrome devtools on my Mac) there was a misalignment of the drop-caps. I anguished over this for ages, unable to know why chrome on my Mac was totally different than chrome on my Android, till I applied a band-aid answer. Now I understand that the reason being that Android makes use of the Win desk for font metrics.
A firefox shock
After all, OS-specific bugs weren’t sufficient, so these drop-caps determined to bestow me with a browser-specific bug as nicely. I’ve had a long-standing battle with Firefox over the alignment of my drop-caps. The foreground and background glyphs have at all times been barely misaligned, and I may by no means work out the correct patch to repair it. However after my font metric repair for Home windows, the Firefox alignment hit the fan, so to talk. Right here’s a picture of what I noticed after enhancing my fonts.
Now I had one of many drop-cap glyphs correctly aligned (the blue) and the opposite bumped up in order that it was misaligned with the paragraph and the foreground glyph. At first, I assumed I had screwed up one of many font edits, since solely one of many two glyphs is misaligned, however I double checked all of them and it was fantastic. Finally, I couldn’t provide you with a great rationalization, so I did a really unhealthy factor it is best to by no means do however I’m nonetheless going to let you know how. You possibly can goal Firefox with a bit CSS hack (which will or could not cease working sometime, and is harmful to make use of). So, I got here up with a easy rule that pushed the misaligned glyph again right down to the place it wanted to be. Right here’s the way you do it.
@-moz-document url-prefix() {
.drop-cap::first-letter {
padding-top: 12px;
}
@media (max-width: 500px) {
.drop-cap::first-letter {
padding-top: 10.5px;
}
}
}A postmortem
In case you’re nonetheless studying this, congratulations, and thanks to your dedication. I hope you realized one thing, or maybe this even helped you resolve an analogous downside. For me, this was very a lot a downside -> answer type of submit, however there’s a variety of questions I left unanswered. Like, if fonts have totally different Win Descent heights, then is all the textual content on a Home windows machine misaligned? The remainder of my layouts look OK based mostly on a cursory look, so why was this one so noticeable? Maybe it was simply because the drop-caps are so massive so the distinction was accentuated, or perhaps solely sure fonts have this Win Descent distinction and the opposite ones are fantastic. It undoubtedly opens up an entire can of worms that I’m undecided I need to get into proper now, however maybe one other day I’ll dig into all of my font recordsdata and see what occurs if I begin harmonizing the vertical metrics for all the things on my website. Who is aware of, perhaps all the things on the net is definitely barely misaligned on Home windows (or on Mac, relying in your perspective), and also you’ve simply by no means seen… that’s fodder for a horror film if I’ve ever heard it.