Live data from Hacker News

Text Rendering Hates You

gankra.github.io

81–90 of 172 posts

Re: Text Rendering Hates You

#81
post #35

>Rendering text, how hard could it be? As it turns out, incredibly hard! Related undesired complexities/heterogeneities I encountered while implementing a simple text drawing API on top of various libraries (cf. "Pain points", near the bottom): https://github.com/jeffhain/jolikit/blob/master/README-BWD.m...

> Libraries don't always provide font metrics, and when they do, these metrics are not reliable, as some glyphs can leak outside of their theoretical box, possibly depending on the used font size, or usage of diacritical marks God yes. I'm building a UI design tool, and running head-first into this reality. I had no idea it was this hard.

It can go the other way, too. It is mathematically impossible to make a font that has the exact same vertical metrics/line-spacing everywhere, so everyone sets the three value sets provided by the OpenType spec to the same values for web fonts. And then you try to render a font with tall glyphs (i.e. Arabic) on Android and find that it actually looks at the font-wide bounding box in the head table to determine metrics. You can't change them because then Android clips everything legitimately outside that box.

Re: Text Rendering Hates You

#82
post #78
post #73

I realize it’s probably too late, but as a graphics person, every time I read about text antialiasing, I wish we could rewind and fix the terminology of “Subpixel antialiasing” and “Greyscale antialiasing”. It seems problematic that greyscale antialiasing involves subpixel sampling and color channels. I’d suggest “LCD antialiasing” to replace “subpixel antialiasing”. And regular antialiasing doesn’t really need a ter…

"Subpixel" makes more sense than "LCD": the technique applies to any screen with illumination units smaller than a pixel (eg. LED screens) so "subpixel" makes perfect sense.

Yes, it makes sense. My beef is not that subpixel doesn’t make sense, it’s that the term is overloaded. Standard antialiasing also involves subpixels and the term makes perfect sense there too. From my perspective, “subpixel” fails to differentiate.

Now, using “Greyscale” to mean color, just not LCD color, that one doesn’t make as much sense to me. Some articles call it “whole pixel anatialiasing” or “traditional antialiasing”, those seem better, but maybe we can assume antialiasing is the regular kind, and only need a term to talk about LCD style antialiasing.

Re: Text Rendering Hates You

#83
post #10

"If you're in Firefox or Chrome, it looks awful" Looks correct in Firefox 69.0.1 on Windows here. In Chrome it looks awful as described. In both the "bow" at the top overlaps the text on the previous line.

Chrome/Blink is in the middle of rolling out a large layout engine change. Chrome 76 behaves more like Safari, Chrome 77 behaves as the article describes.

People also might be (1% prob.) placed into a "holdback" experiment group which has the old behaviour in M77.

Re: Text Rendering Hates You

#84
post #10

"If you're in Firefox or Chrome, it looks awful" Looks correct in Firefox 69.0.1 on Windows here. In Chrome it looks awful as described. In both the "bow" at the top overlaps the text on the previous line.

I get the "awful" look in Firefox if I enable Webrender.

Re: Text Rendering Hates You

#85

Earlier quoted context omitted.

This for sure. I love my iMac 27” 5k simply because how text looks on it so much better than even a 28” 4K. 220 DPI is a magical number

Interesting, my main screen is 160dpi@27", and I would love to try something at 300dpi@27". It's difficult to figure out how much of a difference a screen is going to make at 160 vs 220 vs 300dpi unless you sit down and just work for a few days.

160 vs 220 is pretty obvious to me since I’ve experienced that directly. I’m not sure about 300, I’ve never seen one of those even on a laptop before.

Re: Text Rendering Hates You

#86
post #51
post #43

A few minor things missing in OP (mostly CJK related) - Code point is sometimes not enough to determine the glyph. For example, U+5199 must look different in Simplified Chinese and Japanese. Typically this is handled by using different fonts, but more formally it should be marked with different lang attributes (in case of HTML). - Top-to-bottom writing mode is still pretty much in use in Japanese. HTML support is poo…

Elaboration for "ちょっ" Japanese hiragana chi, small yo, and small tsu. Hiragana is a syllabary (not alphabet!) comprised of 46 sounds. Small hiragana can be used to modify the sound of the leading character to expand the set of available phonemes. Here, "Chi (small)yo" becomes "cho". Small tsu is special. It represents a doubled or germinated consonant. For example ちょっと (chotto) sounds like chot-to. Example: https://m…

geminated not germinated haha it's not a seed :p

Re: Text Rendering Hates You

#87
post #51
post #43

A few minor things missing in OP (mostly CJK related) - Code point is sometimes not enough to determine the glyph. For example, U+5199 must look different in Simplified Chinese and Japanese. Typically this is handled by using different fonts, but more formally it should be marked with different lang attributes (in case of HTML). - Top-to-bottom writing mode is still pretty much in use in Japanese. HTML support is poo…

Elaboration for "ちょっ" Japanese hiragana chi, small yo, and small tsu. Hiragana is a syllabary (not alphabet!) comprised of 46 sounds. Small hiragana can be used to modify the sound of the leading character to expand the set of available phonemes. Here, "Chi (small)yo" becomes "cho". Small tsu is special. It represents a doubled or germinated consonant. For example ちょっと (chotto) sounds like chot-to. Example: https://m…

Japanese is one of the few languages with a worse writing system than English. Hats off to them for it. I do miss the pre-war spellings though, where they wrote things based on 10c pronunciation, eg AU is pronounced OH (like in French).

Tibetan is also in pretty desperate need of spelling reform. I’d love to hear replies about other terrible writing systems.

Re: Text Rendering Hates You

#88

It seems like you’d need to read at least a few dozen languages fluently to be able to meaningfully reason about some of these issues. I can’t imagine what sort of educational background experts on rendering would have.

I've been doing text rendering professionally for a few years now and I wouldn't consider myself fluent in anything other than English and maybe German (I'm a bit rusty in the latter). I can also speak some Japanese, but, other than that, that's it. The rest of my knowledge is a smattering of weird details about various languages that are useful for writing text renderers but terribly unhelpful for actually understan…

Yeah there's a reason all my examples use the same ~3 languages, and only a few random fragments from them. You just need a few examples that demonstrate that something can happen. Everything actually works pretty uniformly, so as long as you have a few examples that cover the interesting cases and handle those cases in a general way, everything tends to work fine. The actual font formats are much more nasty and corner-casey. (Thank god you don't need to deal with that, eh Patrick?)

Same reason I prefer to use imperfect terms that capture the important aspects of the problem-space from an english-speaking perspective. Are ligatures the right word for how arabic and marathi get shaped into glyphs? Maybe not, but as long as you get that the æ ligature can be synthesized from ae by a font, and that this is super important for some languages, you're on the right path.

I don't even know what the fragments I use mean, lol. I like to assume I'm just copy-pasting Arabic swears around. Apparently at least one is just Manish's name?

Re: Text Rendering Hates You

#90

I find it... odd that an article on font rendering is using a 14px forced font size (default: 16px) making the article really hard to read on my 14" laptop screen from a foot away. Subpixel antialiasing on my LCD screen is just not my problem here, author. :)

I mainly prioritize making my pages work reasonably with different zooms and window sizes, since all I really know for certain is that there's no ideal for everyone.

The font settings are just from a copy of bootstrap from like 6 years ago, because I have absolutely no eye for this sort of thing.

Post reply on HN