Comment by tayistay | Hacker News Reader

Comment by tayistay | Hacker News Reader

Text rendering doesn't hate you as much as article implies, AFAICT.

1. "Retina displays really don’t need [subpixel AA]" So eventually that hack will be needed less often. Apple has already disabled subpixel AA on macOS AFAICT.

2. Style changes mid-ligature: "I’m not aware of any super-reasonable cases where this happens." So that doesn't matter.

3. Shaping is farmed out to another library (Harfbuzz)

4. "Oh also, what does it mean to italicize or bold an emoji? Should you ignore those styles? Should you synthesize them? Who knows." ... yes, you should ignore those styles.

5. "some fonts don’t provide [bold, italic] stylings, and so you need a simple algorithmic way to do those effects." Perhaps this should be called "Text Rendering for Web Browsers Hates You." TextEdit on macOS simply doesn't allow you to italicize a font that doesn't have that style. Pages does nothing. Affinity won't allow it.

6. Mixing RTL and LTR in the same selection also seems like a browser problem, but I guess it could maybe happen elsewhere.

7. "Firefox and Chrome don’t do [perfect rendering with transparency] because it’s expensive and usually unnecessary for the major western languages." Reasonable choice on their part. Translucent text is just a bad idea.

Probably could go on. It's a good discussion of the edge cases if you really need to support everything, I suppose.

Note that for (1), you're going to have to explain your logic there, because retina displays still need subpixel rendering. They're nowhere near the print industry's standard 300 dpi, they're (a little less than) 300 ppi. For a "three different colours arranged in in blocks of four" screen, you'd need closer to 1200ppi before "we don't need subpixel rendering" is actually true. Until then, the raster tragedy may become less noticeable to people who are used to reading simplistic orthographies (like English), but it's very much still there for more complex orthographies (like, say, almost every middle-eastern, asian, and east-asian orthography)

Was just quoting the author. But also it appears that Apple disagrees with you, since they seem to have turned off sub pixel AA five years ago in macOS Mojave. See [1]. Indeed when I screen-captured and scaled up the non-western script in the article, there was no sub pixel AA on my Mac.

[1] https://www.reddit.com/r/apple/comments/8wpk18/macos_mojave_...

Well, "need" is subjective. But subpixel rendering has diminishing returns as DPI goes up and (as the article describes) it causes several performance and interoperability problems, so the appropriate DPI threshold to turn it off might reasonably be somewhere lower than parity with print. Everyone agrees it's a good idea on cheap low-dpi displays, but whether it's still worth the costs on so-called "retina" displays is a judgment call.

Grayscale AA is still common on Retina screens, but subpixel AA is rare. Mostly because subpixel AA is difficult to do compositing with transparency with, but also because it's less necessary on Retina screens. The tradeoffs are just to the point that it's not considered worth it.

> Perhaps this should be called "Text Rendering for Web Browsers Hates You" because often you have control over the fonts you use (like in a typical app)

The article specified an assumption that this is about laying out editable rich text, where the user using the program is able to arbitrarily style the text as part of using the program.

Like writing HTML+CSS for a web browser, yes; but also like WordPad, or like a cell in a spreadsheet program, or like the contents of a label field in a view builder. And also like changing text display preferences in a terminal emulator.

Admittedly I missed that assumption in cutting to the meat of the article. However, does WordPad or a spreadsheet really need to synthesize styling when the font doesn't have it?

I just loaded a font without an italic style into TextEdit on macOS, and it won't let me italicize it. It doesn't synthesize italics. I'm assuming the same goes for the rest of Apple's apps.

>> because often you have control over the fonts you use

Good luck with that if you want to support non-Latin scripts. Now you're shipping 100s of MBs of fonts with your app.

No. You use the system fonts, which tend to be good

9 out of 10 designers disagree

And then you no longer have control over the fonts you are using, and it’s worse if you want to write cross platform code. Web and iOS (as far as I can tell), don’t have any way of querying which fonts actually end up getting used to lay out text either, which makes rendering some entered text very difficult.

I will probably end up having to ship entire text layout, font handling, and itemization stack in my wok just to do this correctly. It’s pretty frustrating down in the weeds of it.

Reply on news.ycombinator.com