Aria Beingessner (Gankra) is a Rust developer who writes deep technical posts on language design, ABIs, memory models, and text rendering.
HN commenters recommend the blog for its quality, especially 'Text Rendering Hates You,' which one calls the classic 'falsehoods' analog for text.
> It goes both ways. I certainly hate un-needed complexity but somethings are just complex. Good examples are font rendering https://gankra.github.io/blah/text-hates-you/ and text input https://lord.io/text-editing-hates-you-too/ You think it's going to be easy. It's not. It just isn't.
This reminds me of a talk by Venkat Subramaniam, called "Don't Walk Away from Complexity, Run", here's a recording of it: https://youtu.be/4MEKu2TcEHM?t=343
In it he talked about inherent complexity and accidental complexity, the former being a part of the domain that you're working in, while the latter is introduced accidentally and isn't actually necessary to address the problem at hand.
Often people talk about managing and decreasing the accidental complexity, but what if instead you could reduce the inherent complexity by just trying to do less? For example, instead of trying to do advanced font rendering for almost every single language and writing style known to man, why not just limit yourself to ASCII, left to right typing and monospaced bitmap fonts in certain devices? I'd argue that in many cases, such as embedded devices, that's all that's actually worth doing, though seeking out ways to not drown yourself in complexity due to having limited resources to get stuff done applies elsewhere as well.
As someone else pointed out, a light switch would suffice nicely, instead of trying to write software to handle every possible use case for smart lights. Alternatively, just have an API…
What's frustrating is people who think that they can radically simplify something without knowing anything about it. The same people think they can implement a text editor in 1000 lines of code because that's how the first text editors were made. Why can't we go back to those simple days?
We can't because modern software handles cases that those didn't. For example, rendering and editing text seems straightforward until you look closer. Text Rendering Hates You (https://gankra.github.io/blah/text-hates-you/) and Text Editing Hates You Too (https://lord.io/blog/2019/text-editing-hates-you-too/) are two amazing reads that analyze this in detail. They explain the hidden complexity to the vast majority of us who never knew. We simply slapped down a <textarea> or <EditText> and called it a day.
If we tried to reimplement this stuff from scratch, we would likely start with a simple implementation, then tack on bits when we tried to handle issues like right-to-left layouts, Unicode, emoji, anti-aliasing, text overlapping and so on. All this before getting into implementing features that Dennis Ritchie didn't have to, like supporting plugins, releasing on multiple operating systems, accessibility or even syntax highlighting. Problems already known to and tackled by existing text editors today.
If you look at work outside of your area of expertise and you feel like starting a sentence like "why don't you just ...", then reconsider. If the person you're talking to is halfway…
Lots of reasons.
Font rendering for all of unicode is extremely hard.
https://gankra.github.io/blah/text-hates-you/
Multi-language input is extremely hard
https://lord.io/blog/2019/text-editing-hates-you-too/
Having to download an extra meg or 10 of code does not make your website responsive to start, worse if you're updating it constantly so you're users have to re-download that code every few days, hours.
Support for assistive technologies disappears. A page of HTML is relatively easy to scan for text to read or turn to brail or translate to another language. A screen (not a page) of pixels is not.
Similarly extensions all break. Extensions work because there is a known structure to the page (HTML)
UI consistency disappears. Of course pages already have this issue but it will be much much worse if every site rolls it's own pixel rendering GUI because none of the standard keys will work. Ctrl/Cmd-Z for undo Ctrl/Cmd-A for select all? Similarly maybe the user has changed those keys or is using some other assistive device which all works because things are standardized.
Letting the browser handle what's best for the device probably disappears. Cleartype for fonts? Rendering Text or SVG at the user's resolution (yes that can be handled by the page but will it? up to the site)
Password managers break including the browser's built in one. There's no text field to find so no way to know if this is the place to fill them in.
Spell checking breaks. Same as…
> Instead of trying to decide whether a GUI toolkit is native or not, I recommend asking a set of more precise questions:
>
> * Does text look like the platform native text?
>
> * To what extent does the app support preferences set at the system level?
>
> * What subset of expected text control functionality is provided?
>
> * Complex text rendering including BiDi
>
> * Support for keyboard layouts including “dead key” for alphabetic scripts
>
> * Keyboard shortcuts according to platform human interface guidelines
>
> * Input Method Editor
>
> * Color emoji rendering and use of platform emoji picker
>
> * Copy-paste (clipboard)
>
> * Drag and drop
>
> * Spelling and grammar correction
>
> * Accessibility (including reading the text aloud)
>
> If a toolkit does well on all these axes, then I don’t think it much matters it’s built with “native” technology; that’s basically internal details. That said, it’s also very hard to hit all these points if there is a huge stack of non-native abstractions in the way.
This is it! Browsers handle all of this. It's a ton of work. Many many gui kits start with just ASCII and really don't realize how deep the rabbit hole is for making all of this work.
And as always, if you haven't read them
https://gankra.github.io/blah/text-hates-you/
https://lord.io/text-editing-hates-you-too/
> So subpixel-AA is a really neat hack that can significantly improve text legibility, great! But, sadly, it's also a huge pain in the neck!
When playing around with FreeType's ftview demo program, text rendered with an OTF/CFF font using the Adobe CFF renderer with stem darkening enabled actually looks pretty good with grayscale rendering. Subpixel rendering is not strictly necessary.
> https://gankra.github.io/blah/text-hates-you/#aa-breaks-glyph-caches
I think the author mixes up two concepts here, hinting and subpixel positioning.
A TrueType font can change stuff around on the x and y-axis. Applying hinting on the x-axis messes with your layouting and prevents subpixel positioning on the x-axis. What you do is apply hinting on the y-axis only (FreeType calls this slight hinting, DirectWrite more or less does this -- not quite, but close enough) so you are free to shift glyphs around on the x-axis. This helps with displaying text with a more even texture on LoDPI screens. On *nixes, Chrome does this, Firefox doesn't.
> An engineer could not have willed a system of k-segments into existence and imposed it on users.
They did reduce something that existed to a lower resolution so that it fits into k-segments: how do make o (lower case o), O (upper case o), 0 (zero), D (upper case d), Q (upper case q) coexist on a 7-segment display without ambiguity? You start by deciding that lower/upper case it not important and that only one case for each letter will subsist. That's reduction.
> The 7 segments had to be the subconsciously recognized abstract form of letters this entire time.
There are other languages of which the scripts do not fit in this view. English Roman-derivative alphabet is not "better" because it compresses itself more into a specific-imposed compression format.
https://gankra.github.io/blah/text-hates-you/ from https://news.ycombinator.com/item?id=30330144 is a perfect illustration.