Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Typography is impossible (2016) (medium.engineering)
219 points by pmoriarty on March 16, 2022 | hide | past | favorite | 63 comments


And that is just for western text. Welcome to Chinese/Japanese/Korean/Vietnamese -- Over 50,000 kanji glyphs, hangul, hiragana/katakana/kanji mixed script, language-specific glyph variants with identical codepoints, Left-to-Right, vertical text where some glyphs must rotate but some must not, ruby text, language-specific word wrapping rules, language-specific ligatures that exist but mostly shouldn't be used save for very few occasions, terrible software implementations based on non-understanding of all of the above, ARRRRRGH!


And that sheer amount of glyphs needed to be designed mean that, contrary to the article's claim, the fake or synthesized bold is not a crime but rather a form of self-defense.


Many Japanese fonts I'm aware of do have that many glyphs all manually hand-optimized for the full range of font weights all the way from UltraLight to Heavy. Yes, it's an enormous amount of work; yes, Asian type foundries is serious business.


Yeah, many serious CJK fonts do have multiple weights, but are rarer than Western fonts. Much rarer still, CJK fonts with two or more weights or even the full gamut (100 through 900). This severely constrains typographic choices.


> ruby text

Excuse me?



Not to be confused with Ruby strings, which have their own complexities


Not to be confused with `"ruby".class #=> String` :)


I don’t know why it’s called ruby. If you know Japanese you will know this as “furigana”.

It’s mainly used for added readings to words written using kanji.


"Ruby" is the name of the size of the type


To expand on that for those that don't know, traditionally all font sizes had names, like Great Primer for 18 pt, Ruby for 5.5 pt, and many others. https://en.wikipedia.org/wiki/Traditional_point-size_names


There used to be Infinality which made fonts look amazing on Linux a decade ago. https://web.archive.org/web/20151103070844/http://www.infina... . Now it looks like https://gist.github.com/cryzed/e002e7057435f02cc7894b9e748c5... is a good source of info on how to achieve this. macOS still probably wins on font rendering for whatever reason, but at least we have:

https://en.wikipedia.org/wiki/Droid_fonts

https://fonts.google.com/specimen/Source+Code+Pro

and now

https://fonts.google.com/specimen/Inter


I do mostly front-end development for work, I use a iMac with a 4.5k display, and the few times I start up a Windows or Linux machine and look at how it's rendered I'm really taken aback at how BAD fonts look across the board. And it's not a browser issue; across the entire OS the text just doesn't look right compared to the Mac. The strokes are too thin sometimes, too thick sometimes, edges that should be smooth are unexpectedly jagged... Maybe it's a resolution issue, maybe it's a display issue, maybe that's just how fonts are supposed to look and Mac OS has warped my perception. But they look terrible.


> maybe that's just how fonts are supposed to look and Mac OS has warped my perception

Well, Mac OS users lived with this serious rendering bug for more than a decade: https://www.lighterra.com/articles/macosxtextaabug/

I remember that look well, and even thought that was how text was supposed to look. I stopped using Mac OS before that bug was fixed, so I don't know what else may be going on over there. However, there was a period where a lot of websites looked terrible on non-Macs because Mac-using designers would set really light font weights, which apparently looked fine with Apple's font rendering. Were they right, while everyone else was wrong? I don't know.

Nowadays I run pretty-much-default Ubuntu linux with a 4k display, and I think fonts throughout my system and the web look great, both compared to my iPhone (which also looks great) and compared to my standard definition Windows setup at work (which looks anywhere from 'bad' to 'fine', depending on the program, font, scaling, etc).


> Well, Mac OS users lived with this serious rendering bug for more than a decade

Er, kinda kinda-not. A lot of this article discusses subpixel AA which has been disabled by default on high DPI displays since they were introduced, for all Macs for several years, and the setting hidden in UI and eventually fully removed.

Light on dark text still renders perceptually bolder regardless of measurement, and many dark mode guidelines rightly recommend using slightly lighter font variants in dark mode where that perception feels off. I made this choice with my site even where the system font is used for prose text, specifically because text in dark mode looked heavier for me. But there wasn’t a bug… this was consistent in Safari and rendering contexts that bypass macOS text rendering.


The exact formula for glyph dilation was reverse-engineered and published at https://mobile.twitter.com/pcwalton/status/91899145753235456.... The bug is that the formula isn't 0 for subpixel-antialiased text.


I have mac, windows and linux computers around me right now and find macs to have by far the most terrible, atrocious blurry rendering. It makes my eyes bleed every time I have to use macOS on a non-retina screen.

In contrast looking at text on my linux screen makes me consistently happy, retina or not. https://imgur.com/a/eXQ9YWR


This is mostly my experience. Text looks great on macOS as long as you're on a hi-dpi display, otherwise it looks like garbage.

For a long time linux was painful - but having bit the bullet and moved to wayland, I'm pretty thrilled at how nicely both standard res and hi-dpi screens look there.

I don't really mind windows either way - it's not the prettiest, but it remains fairly readable at most scales.


> but having bit the bullet and moved to wayland, I'm pretty thrilled at how nicely both standard res and hi-dpi screens look there.

... wayland isn't supposed to change font rendering though ? It's just freetype + fontconfig + harfbuzz most of the time and AFAIK they don't operate differently under Wayland or X11 (or even if you build and use them on Win or Mac).


Wayland fixing the scaling issues you hit when mixing/matching hi-dpi and standard screens.

XWayland apps still have a few issues (or at least did, I've mostly moved over to native wayland everywhere now that chromium supports it)

Basically - it's not font related exactly, but it definitely impacts reading text.


Could it be mostly that your Mac is rendering text with 4 times the number of pixels as comparably sized text on other displays?


Is it me or does the font rendering in the screenshots linked in that gist all look very blurry? If I had the choice between that and whatever the default is on linux I'll take the default.


In vscode, tab (the key above capslock) is implemented by counting how many characters are on the current line and adding 4floor(x/4+1)-x spaces to the current line.

This obviously doesn't work if there are non-ascii characters that (have to) use a different font and hence having different widths. Or if you prefer variable-width font, then a purely ascii document will break tab.

The developers reply on github that this (characters having different widths) is a frontend thing and they don't have enough API that can fix this. But of course since vscode is an open source project you can always fork it and fix it yourself.

I don't know any other editor that cannot handle tab.


FWIW, the default behavior in Emacs is that tab indents the line to what its heuristics tell it the line should be at, no matter where your cursor is in the line. This is confusing at first, but as long as the heuristic is correct it's pretty nice (but it drives you crazy when the heuristic is wrong for whatever reason).


I check the document and the it looks great. Even if it fails to work at least you are always brought back to an integer value of x-coordinate.


We've started trimming the whitespace from the top/bottom of blocks of text so that the bounding box is effectively from the top of the cap to the baseline.

Mark Dalgleish describes the technique in this video (around 9:45) https://m.youtube.com/watch?v=jnV1u67_yVg

It's made it a lot easier to reason about the layout of text compared to other elements on the page and achieve more consistent use of spacing.


"Reason" about it -- typography is art. There are many issues that started around when GUI word processing started. For example -- the "spring space" is simply gone. As is the "set indent to current (horizontal and vertical)". Kerning tables are pretty much gone (we used to have kerning by size/font font/combinations. This has not been simple. But typography is, basically, dead.

I have given up "teaching typography".


At the end of the day I'm a developer, not a designer, so I'm not confident to speak to the art/design side of typography.

Having said that, I believe that art (and design) requires intention and thus some amount of "reasoning".


Think of it like this, though. Suppose books were invented second to the computer, not first. They'd be the hottest thing. Everyone would be reading in public and giving up their unreliable and vulnerable smartphones, who could resist the atomic collateral of a book, it simply uses so many more atoms per bit than a chip. Books are so much more trustworthy! I've only witnessed one hack on a book whereas I've seen so so many on computers.

So then, someone would post exactly your comment, but in reverse, "I have given up 'teaching typography'." Why? Because nobody cared about subpixel rendering, rotating screens, SVGs versus rasters, because everyone would be exploring kerning tables and spring space.


I've been doing this as well in some projects. I use Capsize, which I believe is the result of his team's work extracted into its own tiny library. Interestingly, it no longer uses a transform, and now applies negative margins in :before and :after pseudo-elements, as such:

.capsizedText { font-size: 19.25px; line-height: 24px; }

.capsizedText::before { content: ""; margin-bottom: -0.2597em; display: table; }

.capsizedText::after { content: ""; margin-top: -0.2597em; display: table; }

https://seek-oss.github.io/capsize/


Doesn't this necessarily mean that descenders will intersect with the next element? See the `space="xxsmall"` example at 14:17 – "lazy dog" has its "g" dipping into the Submit button sibling.

Depending on how you're calculating the offset, this may also have problems with things like diacritics and non-Latin text, which may be taller (e.g Thai).


Sure, if you put things too close together they will intersect/overlap.

This isn't an inherent problem of the technique though. You should be giving things enough space so that this kind of thing doesn't happen. It should be pretty simple to check that the smallest unit of space used anywhere isn't smaller than the amount being trimmed from the top/bottom of the text box.


> It should be pretty simple to check that the smallest unit of space used anywhere isn't smaller than the amount being trimmed from the top/bottom of the text box.

It might be worth doing that, but note that there is still no guarantee of any reasonable upper bound on the vertical dimensions text will render within. Zalgo text is a famous example that very clearly illustrates this state of affairs [0]. The fact is that no current web design can guarantee that no text glyphs will overlap, short of using some non-standard font that prevents it, or perhaps by greatly restricting the usable Unicode characters.

[0] https://en.wikipedia.org/wiki/Zalgo_text


This is trading typographical consistency issues, then. In this described setup, you'll have glyphs poking into the margin and padding between elements – which is what the existing bounding boxes work to prevent.

Here's an editable interface from that talk: https://seek-oss.github.io/braid-design-system/playroom/#?co...

You can see the issues when we write Hello World in Thai: https://i.imgur.com/MaHfPr3.png


You're wrapping your two Text components with a Stack component which lays out its children vertically, and you're explicitly specifying that Stack uses zero space between each of its children. This doesn't have anything to do with Thai characters specifically. The glyphs already overlap with common English characters like "j" and punctuation like commas. Moreover, you can get glyphs to overlap between two lines of a normal HTML element with line-height: 1 (and obviously even more easily with line-height less than 1).


Yes, but this is true already. Here's a screenshot of how Hacker News looks on MacOS Chrome with some diacritics pasted into the beginning of your two paragraphs:

https://imgur.com/a/nH3KDbZ


Typography used to be an art. Now it's expected to be a science. My (much) older brother was a typographer by trade all his life and most of what he did was by eye, not by measuring.

For various reasons typography has become something everyone dabbles in, but few do well. It should not be a great surprise that something which is an art refuses to completely yield to science.

Personally I have never felt confident with it (for obvious reasons) and just hope to produce something acceptable.


Typography is an artform, but don't blame science for its decline but rather conformism. I've generally known people to weep and wail when something strays an inch from Helvetica, Computer Modern, and Roboto. Therefore, all one needs to do to be an 85% expert at type is put <style>@font { roboto: url(data:...) charset(latin1); }</style> at the top of an html page and everything magically looks good. If I wanted to get into typography then I'd probably do it by learning Arabic since it's all cursive and really complicated, which means plenty of opportunities for creativity.


In many ways the familiarity and apparent simplicity of English text is a big challenge, particularly whole pages of text. A great book to read is Just My Type: A Book About Fonts by Simon Garfield. Turns out I live not too far from the resting place of the only matrices of Doves type, at the bottom of the Thames.

My brother talks about setting whole pages by hand, and finding a word missing! Apparently it pays to leave a bit of extra space.


Actually, divers recovered them in 2014 to augment a digital reconstruction of the typeface: https://typespec.co.uk/doves-type/


From the book

> Fearing it's use in shoddy printing and undesirable subject matter [Cobden-Sanderson] took the entire fund to Hammersmith Bridge and threw it in the Thames.

If after 100 years it is now for sale it feels a bit sad. I hope it is used well.


Totally agree. Typography is similar to grids in the same way.

As a design it's tempting to set up "a perfect grid" so your life will be easier and everything will look great. But it's often better to know how and why grids work, and then create more informal layouts intuitively.


I used to be a typographer's apprentice in a previous life.

Whenever I start adjusting stuff by eye (or ask for it to be done), junior front-end devs freak out and accuse me of various sins such as "cheating" or "guessing".


Presumably it's an inside joke of some sort that the submission title has different capitalization than the article?


I copied and pasted the title from the article and HN capitalized all the words in the title.


I like good website design and that "good design" evolves every year. But how many hours have been spent tweaking fonts in the English language by how many brilliant and creative people?

I wish we could all save each other the time, by agreeing to use a single font in a dozen iterations (e.g. "Universal Serif" vs "Universal Sans" vs. "Universal Fixed Width", like Noto or whatever)

It should be a social imposition to use a different font.

Like: yes, you can do it and people do, but keep in mind you're exercising your right to be creative at the expense of everybody's comfort/convenience, in the same way as a busker on the subway.

If you're very good at what you're doing then you might be brightening everybody's day. But if you're even average at it, you're only annoying people and they will tolerate that annoyance out of social obligation, not because they like it.

That would save everybody the hours, days, and sometimes weeks of picking a font, a keming, a line-spacing, etc, not to mention the annoyance of having to read awkward fonts.

https://fonts.google.com/noto


This sounds a little similar to the hubris of the GNU moe [1] manual. You're assuming you could make a "good enough" font that would truly be "good enough". I don't think you can even come close.

A font adds so much character to the text. Where one font may be appropriate, a different text would look stilted or silly. Fiction, fantasy, technical, non-technical non-fiction, etc. books all require different fonts, in my opinion, to capture the character of the words.

Noto is a fine font, but I don't want to use it for my blog. There are a bajillion fonts that are perfectly legible and for those of us who care, they make a difference.

What would help would be a little education and maybe some UX nudges: stop making Arial the default on stuff, (looking at you, Google Docs) encourage well-built fonts by making them the only default enabled options in your OS, etc. I don't think there is "one font to rule them all", however.

[1]: https://news.ycombinator.com/item?id=29990149


> that would truly be "good enough".

I think 99% of the population could agree on a "good enough" font, if reading comprehension is the goal. In fact, I think 99% of the population just reads the words. Our brains necessarily learn to ignore the fonts. Our brains necessarily learn to ignore even the characters themselves [1].

> There are a bajillion fonts that are perfectly legible and for those of us who care, they make a difference.

I think this demonstrates that the goal is not reading comprehension, which makes agreeing on some "good enough" difficult/impossible.

1: https://www.livescience.com/18392-reading-jumbled-words.html


I feel like Helvetica is essentially Universal Sans, but thanks to licensing fees we've been forced to re-invent that wheel over and over.

> But if you're even average at it, you're only annoying people and they will tolerate that annoyance out of social obligation, not because they like it.

I think this part is already implicitly understood, but everyone thinks that they're above average or that their app is special enough that it really needs a custom font.


> but thanks to licensing fees we've been forced to re-invent that wheel over and over.

The fact that licensing fees are even an obstacle here for adoption of a font designed over half a century ago highlights how broken the current intellectual property laws are. At some point of near-universal adoption, a functioning society should just release such a thing into the public domain and provide the original author a pension for his troubles, instead of worrying about rent-seeker from every amateur designer.


In Sweden everything is in Helvetica. It's really hard to spot text in other fonts except for (rare) logos.


Isn't that what we're doing already? I don't notice a lot of creative font choices these days. More than in the days of Verdana, Arial, and Times; but not by much.

The only sites with more daring typography seem to be artist portfolios or band websites. If there were still a culture of handmade amateur websites I guess we'd have more outsider art variety. But I don't really see it.


> That would save everybody the hours, days, and sometimes weeks of picking a font, a keming, a line-spacing, etc, not to mention the annoyance of having to read awkward fonts.

Thanks for the LOL moment. I had to look closely to see if you had typed kerning or keming


Relevant XKCD: https://xkcd.com/1015/


r/keming


Design is good. It employs a lot of people.

At the other end of the spectrum, we could continue to employ the same typography and UI primitives reusably and forever, getting rid of or repurposing design efforts and design people.

Both choices have trade offs.

The market selected our current methodology and practices, and not for a lack of alternatives, for better or worse.

Design is thought to distinguish your brand and elevate your experiences. Maybe not everything truly needs this, but I don't see enough compelling evidence showing how to compete without it. The market says design is important.


Everybody thinks they are exceptional.


obligatory xkcd about how standards proliferate


> otherwise it will behave like a really, really fast typewriter — it’ll go from left to right, letter by letter, until it hits the other margin, then start again on the next line.

Or until it is switched to a different writing mode, which I would have loved this article to address since a lot of work is happening in the internationalization of layout design to acomódate that the left to right top to bottom is not the default for everyone across the globe


That's why I'm for Ted Nelson's plan where we turn all the computers into dreamtrons and just get the fuck down and leave the fonts for the grandmas.


im impressed by how well it all works. cant think of any API that comes even close. Often not by lack of effort.


(2016)


(2016)!!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: