>> 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.

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 introduces costs elsewhere in the system, so the threshold to turn it off might reasonably be lower than absolute parity with print.

In particular, subpixel rendering introduces performance and interoperability problems when the text is rendered on a layer that's semitransparent, rotated or used on more than one physical display (or that may become one of those things in the future -- that's the really tricky part). Everyone agrees it's absolutely needed on traditional low-dpi displays, but whether it remains a good idea or not on "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.