Faux bolds and fallback glyphs are, in many cases, error states, or they at least deserve a warning. But in development, it’s a frustrating mess. We prefer imperfect visual quality to complete breakage. When a glyph isn’t available, they’ll search down the font stack and substitute a usable-but-not-quite-right replacement. They’ll quietly synthesize a shameful faux bold version if a true bold isn’t available. macOS’s default management tool, Font Book, also doesn’t offer much in terms of browsing - searching for, say “a font that includes tabular numbers” isn’t supported, as far as I can tell.įonts on the web as currently designed – and fonts in general – break quietly, which in my opinion is a real issue. I love Chrome’s Web Developer tools, but they offer little in the way of inspecting fonts. I want more robust tools for inspecting fonts. The way forward is unicode range subsetting, a technique I wish was more common and much more developer-friendly. Not to pick on webfonts too much, because system fonts even are limiting in this way - the system default version of Futura, for instance, only has 439 glyphs and support for a small subset of the world’s languages.Ī webfont with wide Unicode coverage will have poor load performance because it includes so many glyphs, and an efficient font with fewer glyphs will have weaker international support. Their names will have a wide range of characters, like æ and ㄞ, and the content they author will too. The hope is that it’ll be successful enough that people around the world will use the website. The norm for web maps is global coverage, so every map you design with the viewport comfortably centered over some major American city with place names mostly in the ASCII range can be panned over to China, with its hundreds of glyphs, or Japan, with its multiple scripts.įor other websites - like for the ones I’m working on now - the wildcard is user generated data. For maps, that’s the names of places around the world, in their native characters. You can seek a certain harmony here, choosing modes of display that fit the text.īut there are known unknowns: contributed and existing content. When we’re designing websites and other material, we write most of the content and choose how that content is displayed. Working with maps made me think of fonts in a different way. So the browser fell back to a font that did have those characters (I think Menlo), but had a different ratio of width to height, so the lines that included ‘exotic’ characters were misaligned. But nonetheless, the font first in their font stack that was present on my computer – Consolas – didn’t have some of the characters that Monodraw uses in its output. GitHub, to their credit, use something similar to the system font stack: a set of good-looking fonts that are on people’s computers. Your browser doesn’t know whether you intend for all that output to be monospaced or not, only that you chose a certain font and that font happened to have all characters with the same width-to-height ratio, and constant kerning. You don’t write in your CSS stylesheet font-type: monospace, you just specify a monospace font, like font-family: Menlo, monospace. Then I realized: what is monospace? In this case, monospace is a property of a font, not text. Checked in the web inspector that GitHub was showing the correct content. I considered it for a while, checking that Monodraw didn’t have any widely-reported bugs. I pushed the commit, reviewed it on GitHub, and what I saw were misaligned shapes, everywhere. I drew the graphics, chose UTF8 mode, copied & pasted into neovim, and they looked great. I was recently using Monodraw to add illustrations to some code comments, explaining, in this case, how a CSS flexbox layout worked. A few thoughts I’ve had about typography on the web: Monospace fonts are only as monospace as their character support
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |