When Fonts Fall
October 2, 2020 4:11 PM Subscribe
“Fallback fonts are like the bus that picks up the slowest race runners when the street needs to be reopened for car traffic—at that point it’s less about finishing the race, and more about avoiding a disaster” — Marcin Wichary explains how fonts, browsers, and operating systems cooperate to ensure we almost always see the the written word as its writer intended.
browser.display.use_document_fonts = 0
posted by genpfault at 6:16 PM on October 2, 2020 [2 favorites]
posted by genpfault at 6:16 PM on October 2, 2020 [2 favorites]
This is a good article that elaborated a lot of the complexities of font selection well, but my goodness you would be shocked at how fast the web becomes if you force webpages to use your own preferred, preselected and locally available fonts. With an adblocker and tracking protection up, this is the next thing you can do to make your browsing experience faster. Sometimes -often, sadly, this is not recommended for most people’s daily driving - it breaks page layout, but it’s so fast.
posted by mhoye at 6:37 PM on October 2, 2020 [8 favorites]
posted by mhoye at 6:37 PM on October 2, 2020 [8 favorites]
Sometimes -often, sadly, this is not recommended for most people’s daily driving - it breaks page layout, but it’s so fast.
Can you give some examples? I'm curious as to why this is. Assuming fonts are a separate file, the roundtrip to download a font file is significantly less than an image. It might be considered in practice to be a bit of a blocking operation even if the operation itself is not blocking, meaning that you can download and load the remote font file but until WebKit/Blink goes through its rendering pipeline the page layout can't be determined. I know that at one time a major difference between OTF and TTF, among other things, was hinting or how the typesetting worked between letters. It makes more of a difference on poor resolution or where you want fine grained control over type setting. The more granular the hinting the more rendering time it takes in figuring out where to position the letters for every character and in turn how the page is laid out.
Also layouts shouldn't break based on the font size within reason. I believe the term used now is flow but for responsive and accessibility reasons if you're seeing issues by setting things to sans-serif vs whatever special font you're using within reason the layout shouldn't break.
posted by geoff. at 6:56 PM on October 2, 2020 [1 favorite]
Can you give some examples? I'm curious as to why this is. Assuming fonts are a separate file, the roundtrip to download a font file is significantly less than an image. It might be considered in practice to be a bit of a blocking operation even if the operation itself is not blocking, meaning that you can download and load the remote font file but until WebKit/Blink goes through its rendering pipeline the page layout can't be determined. I know that at one time a major difference between OTF and TTF, among other things, was hinting or how the typesetting worked between letters. It makes more of a difference on poor resolution or where you want fine grained control over type setting. The more granular the hinting the more rendering time it takes in figuring out where to position the letters for every character and in turn how the page is laid out.
Also layouts shouldn't break based on the font size within reason. I believe the term used now is flow but for responsive and accessibility reasons if you're seeing issues by setting things to sans-serif vs whatever special font you're using within reason the layout shouldn't break.
posted by geoff. at 6:56 PM on October 2, 2020 [1 favorite]
This is a great overview of a lot of hard work which has happened over the years to make the web work as well as it does now.
In ancient days before Unicode, you had problems like text looking correct to someone who can’t read it depending on the font. Back in the 90s I had a translator sending us simplified Chinese but saying with absolute certainty it was the traditional Chinese our client’s Taiwanese readers expected. With some characters in common this apparently missed review repeatedly until someone reported it as a bug.
Unicode becoming pervasive and Microsoft and Apple shipping system fonts with massive coverage put and end to that period but then we had a decade or so where you’d get interesting failures with less common features. I used to work on a project which had pretty global coverage (text in 140 languages) and we ran into a fun one with combining half circle accents (“Ḟedosi︠e︡ich”) didn’t align which was due to finding the relatively obscure accent glyphs in a different font, which as a bonus was worse in most browsers because someone had used “Arial Unicode MS” in the stack because many years ago that had had better coverage and that stopped being true years later. No good deed goes unpunished and all.
We found similar issues affecting some scripts which have complex combining ligatures, such as Javanese which were dependent on the OS and rendering engine. Firefox switched to SIL’s Graphite engine and for years was ahead in both quality and consistency across platforms until Chrome similarly took full control over text rendering to have enough control.
posted by adamsc at 6:59 PM on October 2, 2020 [5 favorites]
In ancient days before Unicode, you had problems like text looking correct to someone who can’t read it depending on the font. Back in the 90s I had a translator sending us simplified Chinese but saying with absolute certainty it was the traditional Chinese our client’s Taiwanese readers expected. With some characters in common this apparently missed review repeatedly until someone reported it as a bug.
Unicode becoming pervasive and Microsoft and Apple shipping system fonts with massive coverage put and end to that period but then we had a decade or so where you’d get interesting failures with less common features. I used to work on a project which had pretty global coverage (text in 140 languages) and we ran into a fun one with combining half circle accents (“Ḟedosi︠e︡ich”) didn’t align which was due to finding the relatively obscure accent glyphs in a different font, which as a bonus was worse in most browsers because someone had used “Arial Unicode MS” in the stack because many years ago that had had better coverage and that stopped being true years later. No good deed goes unpunished and all.
We found similar issues affecting some scripts which have complex combining ligatures, such as Javanese which were dependent on the OS and rendering engine. Firefox switched to SIL’s Graphite engine and for years was ahead in both quality and consistency across platforms until Chrome similarly took full control over text rendering to have enough control.
posted by adamsc at 6:59 PM on October 2, 2020 [5 favorites]
I used to work on a project which had pretty global coverage (text in 140 languages)
Out of curiosity what product required this? I worked on a large, global project and everything really ended up being simplified Chinese, English and Spanish. These were medical texts so the audience was highly educated and most vocabulary stemmed from the Western canon so you didn't get obscure things, but I can't imagine outside of obscure academia would ligatures for Nikolaĭ Ḟedosi︠e︡ich actually be necessary or even wanted (note: this is currently broken on Metafilter in Preview on Chrome dev channel on Big Sur).
posted by geoff. at 7:15 PM on October 2, 2020
Out of curiosity what product required this? I worked on a large, global project and everything really ended up being simplified Chinese, English and Spanish. These were medical texts so the audience was highly educated and most vocabulary stemmed from the Western canon so you didn't get obscure things, but I can't imagine outside of obscure academia would ligatures for Nikolaĭ Ḟedosi︠e︡ich actually be necessary or even wanted (note: this is currently broken on Metafilter in Preview on Chrome dev channel on Big Sur).
posted by geoff. at 7:15 PM on October 2, 2020
The World Digital Library, which was only translated into 7 languages but had fragments, usually the original language, in all of the content languages (I also had to worry about mixing RTL since one site language was Arabic). Obscure academia describes a fair chunk of the collection but that audience is also highly attuned to errors.
Arabic had another fun issue: we used to use the Eastern Arabic numerals in the UI for that language but stopped because there was disagreement about using those or the Persian variant and you’d need geolocation to try to load the right symbols. Several of our regional partners mentioned that they used the Western Arabic numerals exclusively because it was easier than dealing with complaints or confusion since apparently a fair number of people are only familiar with one form.
posted by adamsc at 8:01 PM on October 2, 2020 [4 favorites]
Arabic had another fun issue: we used to use the Eastern Arabic numerals in the UI for that language but stopped because there was disagreement about using those or the Persian variant and you’d need geolocation to try to load the right symbols. Several of our regional partners mentioned that they used the Western Arabic numerals exclusively because it was easier than dealing with complaints or confusion since apparently a fair number of people are only familiar with one form.
posted by adamsc at 8:01 PM on October 2, 2020 [4 favorites]
When I worked on the print engine in Microsoft Access 1.0 at Microsoft, I got a bug in my bug list related to fallback fonts. Back then, there was a screen font only called System (back then TrueType fonts were just coming in). If you designed a form using that font, it looked great in Print Preview. However, if you went to print it on a PostScript printer, it came out as gibberish.
Windows has an algorithm for finding a font "near" the font you asked for, which looked at the font metrics of the fonts that were available on the device you were using. If it didn't find a font that was "near" the font you asked for, it arbitrarily used the last font that was available. There was no font "near" System on a PostScript printer. On a PostScript printer, the last font among the fonts that were available was WingDings. Some people had trouble reading the form after it was printed.
The bug was a "won't fix", but we changed the fonts we used so that using System on forms was discouraged.
posted by Xoc at 9:01 PM on October 2, 2020 [14 favorites]
Windows has an algorithm for finding a font "near" the font you asked for, which looked at the font metrics of the fonts that were available on the device you were using. If it didn't find a font that was "near" the font you asked for, it arbitrarily used the last font that was available. There was no font "near" System on a PostScript printer. On a PostScript printer, the last font among the fonts that were available was WingDings. Some people had trouble reading the form after it was printed.
The bug was a "won't fix", but we changed the fonts we used so that using System on forms was discouraged.
posted by Xoc at 9:01 PM on October 2, 2020 [14 favorites]
Oh, I think I was bitten by that issue with Wingdings and System, though not on Access.
posted by Monday, stony Monday at 2:47 PM on October 3, 2020 [1 favorite]
posted by Monday, stony Monday at 2:47 PM on October 3, 2020 [1 favorite]
I knew a lot of (probably even most of, but somehow not .notdef) the disparate facts presented here already, but the mental model of the sieve somehow hadn't occurred to me and makes understanding what the systems are intended to do so much easier.
Collections of trivia are great and all, but they don't do much in the way of contributing to understanding. Too bad my brain is mostly a trivia machine.
posted by wierdo at 3:57 PM on October 3, 2020 [2 favorites]
Collections of trivia are great and all, but they don't do much in the way of contributing to understanding. Too bad my brain is mostly a trivia machine.
posted by wierdo at 3:57 PM on October 3, 2020 [2 favorites]
In a previous life working on Mapbox Studio, a map design tool, font fallbacks were extremely important because labels on countries are in the local language, usually. I built this feature that still survives, four years later - that analyzes all the fonts, compares them to the glyphs used in a variety of languages, and shows you a prediction of what language will use which font. There's a UI with bar graphs for each language. I'm not sure this exists anywhere else!
One of the weirdest discoveries, while analyzing languages everywhere, is that a lot of 'English' labels are written using half & full-width forms, which are the same letter but a different codepoint.
Another weirdness is around monospace fonts, which are only monospace for supported glyphs, so if you have UTF-8 text in a monospace font, it's not necessarily… monospace.
posted by tmcw at 4:10 PM on October 3, 2020 [3 favorites]
One of the weirdest discoveries, while analyzing languages everywhere, is that a lot of 'English' labels are written using half & full-width forms, which are the same letter but a different codepoint.
Another weirdness is around monospace fonts, which are only monospace for supported glyphs, so if you have UTF-8 text in a monospace font, it's not necessarily… monospace.
posted by tmcw at 4:10 PM on October 3, 2020 [3 favorites]
I still get fallback characters regularly on my computer because Windows 10 has font issues in that common ones like Arial and Times New Roman get corrupted and are hard to fix.
Great article though.
posted by blue shadows at 12:06 AM on October 4, 2020
Great article though.
posted by blue shadows at 12:06 AM on October 4, 2020
« Older "Since you do well in all subjects, you can major... | A Book Of Beasts Newer »
This thread has been archived and is closed to new comments
posted by doubtfulpalace at 4:49 PM on October 2, 2020 [1 favorite]