15 ms·

Text Rendering Hates You (2019)

399 points by WayToDoor 5y ago

tripa 5y ago
That was fascinating. Thank you.
steerablesafe 5y ago
> Greyscale-AA is the “natural” approach to anti-aliasing. > Subpixel-AA is a trick that abuses the common way pixels are laid out on desktop monitors. I disagree with this notion of subpixel-AA being "abuse". If anything, grayscale AA is a simplification, assuming that each color component of a pixel is emitted from the same area. Of course subpixel-AA is more complicated, but it doesn't mean that it's abuse.
- opoolaka 5y ago
  It's a hack/trick since it exploits a hardware layout that wasn't meant to be used from the software side. Like most hacks, it can work for some common use cases but will have a lot of edge cases : - how to detect the user pixel layout? on web, native applications.. - what about users who switch between landscape/portrait orientations? - does it make correct gamma rendering more complex? switch to dark mode harder? Also, I cannot find a simple implementation, focused on subpixel-AA. So people will probably have to start from scratch.. Here is the most interesting link I found: https://www.grc.com/cttech.htm https://www.grc.com/cttech.htm
  - jcelerier 5y ago
    > - how to detect the user pixel layout? on web, native applications.. 99% of the monitors are RGB. BGR monitors are an oddity.
    - boondaburrah 5y ago
      My CRT would like to speak with you. More seriously, it seems every phone screen invents it's own pixel layout and of course, can be rotated 90° at any time.
      - Gankra 5y ago
        The fact that there are many different pixel layouts on phones is kinda irrelevant since they've largely all converged on retina resolutions for their viewing distance, making subpixel entirely pointless. For this reason, to my knowledge no one has ever bothered designing pentile subpixel rendering or whatever. Like I'm sure there's a cute tech demo but no one has any reason to seriously design and ship such a thing. Same situation with the vast majority of macs. Apple just disables subpixel at the OS level since most things are retina anyway. It still has its practical applications when you have the kind of userbase Firefox or Chrome does, but yeah it's increasingly easy to just Not Bother.
    - kevingadd 5y ago
      As soon as phones, tablets, and hybrid laptops (i.e. surface, etc) enter the picture you can no longer assume RGB because users rotate the device. People now stream PC/console games on their phones, too. Incidentally 'vertical sync is vertical' is also no longer a correct assumption. In some cases if you rotate a device now the tearing (when vsync is off) is vertical instead of horizontal, which is really disorienting if you're not used to it.
    - dspillett 5y ago
      But they do exist, as do other sub-pixel layouts (pentile, RGBG, ...). If you use sub-pixel rendering assuming RGB you are going to look worse on some devices (many Samsung phones, IIRC). Also, if you use sub-pixel tricks in static resources such as images (or your text renderer is not aware that the sub-pixels may not always be arranged horizontally) you are going to have colour halo effects when a device is rotated. Windows is doing that (optimising for horizontal RGB, when vertical RGB is the reality) right now on the screen I have rotated to portrait aspect. It isn't stark enough that I can see any colour halo at this dot pitch, in fact the effect is very subtle, but seen side-by-side text looks a little blury on that screen compared to the other screen (practically the same dot pitch, but landscape so actually is a horizontal RGB layout). Someone with better eyes (mine are somewhat shite) might find it more irritating that I do. I must get around to telling Windows to just use greyscale text trickery...
    - kuschku 5y ago
      I use one monitor in portrait mode, one in landscape. Something relatively common for devs.
  - steerablesafe 5y ago
    Yes, it's more complicated, and parts of it might need hacks, as there are no standard way to get subpixel layout. That's a failure of those display APIs though, not the failure of the concept of subpixel-AA itself. > does it make correct gamma rendering more complex? switch to dark mode harder? Most text rendering is gamma-incorrect anyway, AFAIK, subpixel-AA or not. It doesn't make it more complex, just work in a linear colorspace either way.
- d_tr 5y ago
  Subpixel AA literally gets the colors wrong at the boundary, so calling grayscale AA a simplification is a bit too much IMO. Some people prefer subpixel AA and it might even be a matter of accessibility for others, so its existence is a good thing I guess, but it is not grayscale that makes any false assumptions.
  - steerablesafe 5y ago
    Pixel boundaries on your display are imaginary, all you have are RGBRGB light sources next to each other. The pixel boundaries are determined by your left-most and right-most light sources on the display, so you have |RGB|RGB|..., but it really shouldn't affect how you render text in the middle of your screen. edit: > it is not grayscale that makes any false assumptions Grayscale assumes that those pixel boundaries are real, and they are relevant.
    - kevingadd 5y ago
      This assumes you actually have RGB light sources in that order. There are (were?) consumer displays with RGBW or other alternative arrangements out there, not to mention panels with a different color ordering. And if you rotate or invert the display, the ordering becomes different. An ordinary consumer will never understand what's going on here, so if your code assumes RGB subpixel rendering for text is always correct, it's just going to look ugly to them for no reason.
      - steerablesafe 5y ago
        I was assuming that to make a point. The actual subpixel order can either be retrieved by an appropriate API (if available) or be provided by the user (display settings). Point being, subpixels don't usually overlap on the same area, which is what's grayscale's assumption. I agree that if subpixel order is not known, then grayscale is a sane default.
        user-the-name 5y ago
        If your stroke is 7 subpixels wide, it will be, for instance, RGBRGBR. That has three Rs, two Gs, and two Bs. That is 50% more red light than blue or green. That is tinted red, no matter how you look at it. Subpixel antialiasing does distort colours. That is just a physical fact. The only reason it works at all is that on average, it will even out to a uniform white. But in the details, it will not. Especially around straight vertical edges.
samwillis 5y ago
If text rendering hates you, an editable text renderer is 10x worse. Anyone who has spent any time working on contenteditable or any of the browser based rich text editors knows what a nightmare it is. The temptation to abandon all hope and start from scratch with a canvas element and build you own renderer and editor is strong. You start researching how to do it, maybe even create a quick prototype but quickly discover all the edge cases in this article and more. People who have spent significant parts of their career fixing all the inconsistencies between browsers and devices such as Marijn Haverbeke with ProseMirror (and CodeMirror) should get a Gallantry award for the work they have done.
- jahnu 5y ago
  It's pain all the way down على طول الطريق uʍop ʎɐʍ ǝɥʇ llɐ
  - alpaca128 5y ago
    Maybe it's just on my side but the l's in the flipped "all" seem to be either displayed upright or not at the correct height. Which would only support the linked article.
    - saithir 5y ago
      For extra pain, you can go at the text above with your browser's devtools and change the font-family to something funny like Comic Sans MS. Turns out text rendering _really_ does hate you.
    - tialaramex 5y ago
      The flipped text is doing a trick where you pick things from Unicode that merely look like upside down Latin letters. Some of them deliberately are exactly that for whatever reason, some aren't. So the effect isn't exactly perfect and shouldn't be. There isn't actually a plain text way to say "for some reason render this upside down" because like, why.
      - 5y ago
EasyTiger_ 5y ago
Clickbait titles are getting worse and even more nonsensical
- ChrisMarshallNY 5y ago
  That’s the article title, and the article is over two years old, so I’m not sure it’s an effective data point for the diagnosis.
  - kzrdude 5y ago
    It's kind of an off-putting title for a good article, to be honest.
    - ChrisMarshallNY 5y ago
      I agree. It is an excellent article. Text systems are weird. There's an entire book about strings, in Swift: https://flight.school/books/strings/ https://flight.school/books/strings/
- blinkingled 5y ago
  OTOH I would have never read an article on Text Rendering if it wasn't for a clickbait title :) - IOW totally justified for the good cause of making people more aware of obscure yet interesting topic they never cared about!
iqanq 5y ago
ascii using cleartype seems to work fine for me, I don't see the issue.
nyanpasu64 5y ago
Another Fun(tm) rendering bug: In Firefox, when a word is split across lines between two characters normally connected by a ligature, the ligature doesn't get disabled and the two characters rendered separately, but the ligature is sliced in half and rendered across lines: - https://bugzilla.mozilla.org/show_bug.cgi?id=479829 https://bugzilla.mozilla.org/show_bug.cgi?id=479829 - https://bug479829.bmoattachments.org/attachment.cgi?id=363733 https://bug479829.bmoattachments.org/attachment.cgi?id=36373...
- chrismorgan 5y ago
  The fun thing here is that as soon as I read Firefox, I knew it was going to be the split ligature issue. There are so few text rendering issues in Firefox, and that’s probably the only one most people will ever encounter.
  - andjd 5y ago
    My reaction to this was how would this ever be a common issue? When would you naturally have a line break in the middle of a ligature. The screenshots show the answer: auto hyphenation. But at the point you're dropping a hyphen between the elements of a ligature, how do you not break up the ligature into two independent glyphs?
    - zerocrates 5y ago
      I assume the basic issue is that by the time they've decided how big the text is (and therefore if/where they need hyphenation), they've already decided to use the ligature. Dynamically deciding whether or not to use the ligature when its at the linebreak seems expensive... refusing to do a ligature in the presence of a soft hyphen and otherwise treating the ligature as a single unit that cannot be broken seems like the more tractable way out of the problem... but I'm sure I'm avoiding or unaware of some additional piece of complexity.
- moffkalast 5y ago
  There is something profoundly weird with text rendering in Firefox. Having used Chrome for years and then switched for a while I tried all the different antialiasing modes in the config but neither of them look the same as Chrome somehow, it's all just a tiny bit off and it's so unnerving. Also if you have an input box in html with a size value set to the number of chars you need, that value will be always too short in Firefox, so you have to set it to some multiple which then renders too long in all other browsers where it resolves correctly. I think it's been logged on bugzilla and closed as wontfix, as usual. Typical firefox development cycle.
DiabloD3 5y ago
AA is bad if you do not have a concept of how gamma works. If you have a program[1] that does not understand the difference between sRGB and Linear RGB, the color fringing is extremely nasty, especially on light-on-dark situations. If they don't get the gamma wrong, they get the blend mode wrong (cough Alacritty at one point cough) The fix, honestly, is moving to 200% resolution screens (such as 4k 24" replacing everyone's 1080p 24", or 2880p 27" replacing everyone's 1440p 27"), and using greyscale AA: fonts are now so big, pixelwise, that hinting doesn't screw up fonts, hand hinting is no longer relevant, and any given renderer has a lot of trouble screwing it up. Greyscale with wrong gamma and/or wrong blend mode isn't fatal, it is fatal with subpixel. 1: Such as ClearType on Windows, but not the modern DirectWrite engine. Win10 tried to improve ClearType to make it look more like DirectWrite, but only made its error less harsh. Early versions of Freetype that had subpixel rendering also did this wrong.
- zamalek 5y ago
  > such as 4k 24" replacing everyone's 1080p 24" The problem is the prevalence of 1080p. 1440p on 24" becomes 'retina' at 28" viewing distance (vs 37" for 1080p and 19" for 4k). Grayscale anti-aliasing at that pixel density is really good, gaining you a few inches of viewing distance. I would personally like to see something commonly available between 1440p and 4K (the jump in resolution is abnormally significant). If you've worked on a high refresh rate it's also really hard to drop down and, currently, it's still mostly a choice given the bandwidth and compute requirements. The difference between 60Hz and 144Hz is like the difference between 480p and 1080p, even for tasks like text editing. 60Hz is fucking awful.
- GekkePrutser 5y ago
  I run 24" @ 4K at 200% scaling and it's amazing. But 24" 4K is very hard to get now. All 4K screens I can buy here are 27" and up..
- steerablesafe 5y ago
  > Greyscale with wrong gamma and/or wrong blend mode isn't fatal, it is fatal with subpixel. I might not be fatal with black-on-white or white-on-black, but grayscale is pretty much still horrible with colored text and background.
Semaphor 5y ago
Both Chrome and FF seem to have fixed their text rendering with intersecting cursive glyphs since 2019 :)
- black3r 5y ago
  not on Linux.
  - Semaphor 5y ago
    Ah, so maybe that was always only an issue on Linux, it’s fine on Windows.
    - Gankra 5y ago
      No it was a cross platform issue when I wrote the article. It's pretty fundamental to how most engines render text. That said, text rendering generally involves some amount of platform-specific APIs to get a "native" look and feel. I still see it on the latest Firefox nightly on MacOS. I know Windows DirectWrite handles the issue (which is why Edge handles this issue so well), so if the that's being used more it would probably help.
gjvc 5y ago
Excellent summary. Text rendering and content creation and layout (of which text is fundamental) are central to the creative experience on a computer. Anyone know any well-known (or otherwise) fora for discussing these kind of existential-level concepts?
aasasd 5y ago
Huh, this is not that story where the author, and possibly other people, spent over 1.5 years attempting to redo their text renderer/editor, and had to abandon the project in the end.
- rainbowjelly 5y ago
  Do you mean this [1]? It links to the referenced article too. [1] https://lord.io/text-editing-hates-you-too/ https://lord.io/text-editing-hates-you-too/
  - aasasd 5y ago
    Yeah, that's it.
jfk13 5y ago
Previous discussion: https://news.ycombinator.com/item?id=21105625 https://news.ycombinator.com/item?id=21105625 (but well worth re-visiting from time to time).
HelloNurse 5y ago
Several of the initial definitions are brilliant (like defining emoji by their use of multiple colours), but some are misleading or even incorrect (for example, ligatures draw multiple consecutive scalars, but are made up of one or more glyphs; scripts are sets of scalars, not of glyphs).
perlgeek 5y ago
[2019] (still awesome!)
tomjonesey 5y ago
FrostKiwi 5y ago
Everyone is in the mood to write about text rendering today for some reason, love it. Great to see so many points paralleled like this article talking [1] about sub-pixel offsets being a challange and Nuklear's Wiki article talking [2] about snapping glyphs to an interger offset. [1] https://gankra.github.io/blah/text-hates-you/#subpixel-offsets-break-glyph-caches https://gankra.github.io/blah/text-hates-you/#subpixel-offse... [2] https://github.com/Immediate-Mode-UI/Nuklear/wiki/Complete-font-guide#pixel-snap https://github.com/Immediate-Mode-UI/Nuklear/wiki/Complete-f...
fjfaase 5y ago
Interesting read. I remember having to implement Unicode support and RTL in a graphic library (based on some version of InkScape, if I am not mistaken) that was code page. I implemented it using Uniscribe. The article 'Uniscribe: The Missing Documentation & Examples' was of great help implementing it. However, when I had to implement fallback fonts (for when the standard font does not contain the character you want to display and you want to get it from a different font) I got stuck because I discovered that at time (around 2015/2016) it was not implemented because MicroSoft had replaced Uniscribe by something new. There is also something interesting about the cursor moving through a miked LTR RTL text. It jumps over a character, meaning that it goes through different location depending on whether you move forward or backwards through the text, where forwards means that the cursor moves backwards on the screen when going through a bit of RTL text.
deleted 5y ago
[deleted]
The_O_King 5y ago
Oh this article is back! This is a shot in the dark, but perhaps someone could help me; I remember a link was posted at one point or another about font rendering as well, but from a design perspective about the considerations that need to be taken when designing a font, how glyphs are connected for different languages, etc. - it was presented quite beautifully, with many highlighted examples. Unfortunately all I remember from the site was that it had a green/teal theme to it :( and I haven't been able to find the link ever since Does anyone have any clue what I'm talking about? Pointers would be appreciated :)
LinAGKar 5y ago
In my experience, subpixel antialiasing works reasonably well for dark-on-light, but it looks terrible for light-on-dark.
sharikous 5y ago
Having different styles for elements in ligatures makes sense in some other situations too. E.g. you want to emphasise the accent on a letter when you are teaching the language, I found myself doing exactly that with Hebrew and punctuation, and I stumped upon this problem
korse 5y ago
I run a big CRT monitor with one terminal window and bitmap fonts. I've never had an error using this setup, except when something tries to use a character that isn't in my font and I get a �. This is rare. I've also programmed FPGAs to act as serial terminals and had zero problems perfectly displaying bitmap text. If you get something you can't perfectly display, chances are you don't need to display it so you mark it and throw it out (or you have a bitmap version handy). Due to these experiences, stuff like this seems like a major case of 'too much complexity'. Why is this sort of fancy text rendering so important (for a english speaking and writing person that can pretty much do all work and hobby projects in ASCII)?
- layer8 5y ago
  > (for a english speaking and writing person that can pretty much do all work and hobby projects in ASCII) Most people are not English-speaking/writing and expect “fancy” fonts to not be rendered in a crappy way. Also, the relative blurriness of your CRT alleviates some of the problem. The low-res, mostly latin-only font-rendering world of thirty years ago was certainly simpler.
- fatbird 5y ago
  "An english speaking person able to work entirely in ASCII" is a single use case that still leads to that complexity: we have emojis because people started drawing things with ascii characters. More recently, we have fonts for coding allowing for ligatures, and they're popular among a significant number of your fellow english speakers who could work entirely in ASCII. Even then, much of the complexity outlined in the article still appears when you consider variable width fonts--really, your use case is english user, using only ASCII in a monospaced font. Variable width fonts need kerning, and to accommodate changes in glyph size based on italic or bold variations. Also, English has ligatures like æ, so if you want to deal with older English texts you need them. And then what do you do if you're working in English but need to discuss other languages, even just common European ones with accents? So your use case is now english ASCII monospace user working who's basically just programming with their editor, and this is a very, very narrow use case considering the rest of English speaking/writing users who want to use computers in their own lives. Now multiply all the complexity I've sketched out for every language on Earth spoken/written by some community that would also like to use computers.
phkahler 5y ago
6.1 Fonts Can Contain SVG That whole section needs to go. Don't embrace any non-standard stuff. Fortunately support is poor, so let's hope Google doesn't add support for this in Chrome or it may become popular enough that everyone has to support it.
- CryZe 5y ago
  They just extended the COLR spec to COLRv1 which essentially is a whole new canvas API in fonts: https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md https://github.com/googlefonts/colr-gradients-spec/blob/main...
- Gankra 5y ago
  Ah ok! We'll be sure to drop looping support from Animated GIFs too, because that's also non-standard[0] and is just an extension Netscape 2.0 slapped on there. I regret to inform you the vast majority of the web is just Shit People Tried and that became popular enough for everyone else to support, with lots of hacks to make things interoperate better. [0]: https://en.wikipedia.org/wiki/GIF#Animated_GIF https://en.wikipedia.org/wiki/GIF#Animated_GIF
jancsika 5y ago
> 6.1 Fonts Can Contain SVG This is amazing-- it means someone can design a font where glyphs consist only of SVG elliptical arcs! Ooh even better-- the font designer could place the arcs in such a way that setting large-arc and sweep flags would generate different glyphs. If someone has not designed such a font in the year 2022 then what are the large-arc and sweep flags even for? How can we seriously continue calling this site Hacker News? Why isn't this very comment full of SVG arcs?!? Edit: OMG what about animating the large-arc and sweep flags in an SVG-based font? I want a transition that starts at war with Eastasia on a Monday and ends on war with Eurasia on a Tuesday. We have the technology
warent 5y ago
I built my business around font rendering! Shout out to Behdad https://en.wikipedia.org/wiki/Behdad_Esfahbod https://en.wikipedia.org/wiki/Behdad_Esfahbod a one of a kind man doing god's work. If you've seen text on a screen, you've seen Behdad's work. I've had the lucky opportunity to chat with him briefly and he personally helped me debug a text rendering problem. He's a great guy! Glyphs are registered, text is shaped, and everything is drawn via a ballet of various libraries, often with Pango and Cairo: https://pango.gnome.org/ https://pango.gnome.org/ https://docs.gtk.org/PangoCairo/ https://docs.gtk.org/PangoCairo/ By the way, if you think this is interesting, you might also be curious to read about how fonts are installed/registered on Unix systems. It is a rabbit hole involving a key piece of software on pretty much every computer in the world called Fontconfig (also by Behdad) https://en.wikipedia.org/wiki/Fontconfig https://en.wikipedia.org/wiki/Fontconfig Text and fonts are HARD. Give a hand to those who work tirelessly behind the scenes on this stuff for us. ( Shameless plug of my site https://fontpeek.com/ https://fontpeek.com/ )
bob1029 5y ago
Can confirm this is very hard to do. I was able to create my own 2d text rendering primitive from scratch (for fun), but it has the following "features": 1 font 4 font sizes 16 foreground colors 2 background colors Support for a generous subset of ASCII characters Text wrapping which succeeds as expected in ~50% of cases DPI "agnostic" The only thing that I could ever got any traction with was rasterizing every combination of font/size/color into some texture atlas and then using a dictionary of coordinates & dimensions around each for lookup & calculation. Clearly, this approach falls flat on its ass once you involve non-trivial requirements (i.e. beyond a subset of ASCII), or a variety of fonts/sizes/colors which create adverse combinatorics. That said, when you can reduce any problem space to composition of basic 2d images, things get really simple to think about.
andrewflnr 5y ago
On my Firefox/Fedora browser, the "tofu" glyph seems to have turned into... a goat? Cow? Is anyone else seeing this? Do I just have weird system fonts? How do I even research this? I guess it helps illustrate the article's point, anyway.

399 points by WayToDoor 5y ago

That was fascinating. Thank you.

> Greyscale-AA is the “natural” approach to anti-aliasing. > Subpixel-AA is a trick that abuses the common way pixels are laid out on desktop monitors. I disagree with this notion of subpixel-AA being "abuse". If anything, grayscale AA is a simplification, assuming that each color component of a pixel is emitted from the same area. Of course subpixel-AA is more complicated, but it doesn't mean that it's abuse.

opoolaka 5y ago
It's a hack/trick since it exploits a hardware layout that wasn't meant to be used from the software side. Like most hacks, it can work for some common use cases but will have a lot of edge cases : - how to detect the user pixel layout? on web, native applications.. - what about users who switch between landscape/portrait orientations? - does it make correct gamma rendering more complex? switch to dark mode harder? Also, I cannot find a simple implementation, focused on subpixel-AA. So people will probably have to start from scratch.. Here is the most interesting link I found: https://www.grc.com/cttech.htm https://www.grc.com/cttech.htm
- jcelerier 5y ago
  > - how to detect the user pixel layout? on web, native applications.. 99% of the monitors are RGB. BGR monitors are an oddity.
  - boondaburrah 5y ago
    My CRT would like to speak with you. More seriously, it seems every phone screen invents it's own pixel layout and of course, can be rotated 90° at any time.
    - Gankra 5y ago
      The fact that there are many different pixel layouts on phones is kinda irrelevant since they've largely all converged on retina resolutions for their viewing distance, making subpixel entirely pointless. For this reason, to my knowledge no one has ever bothered designing pentile subpixel rendering or whatever. Like I'm sure there's a cute tech demo but no one has any reason to seriously design and ship such a thing. Same situation with the vast majority of macs. Apple just disables subpixel at the OS level since most things are retina anyway. It still has its practical applications when you have the kind of userbase Firefox or Chrome does, but yeah it's increasingly easy to just Not Bother.
  - kevingadd 5y ago
    As soon as phones, tablets, and hybrid laptops (i.e. surface, etc) enter the picture you can no longer assume RGB because users rotate the device. People now stream PC/console games on their phones, too. Incidentally 'vertical sync is vertical' is also no longer a correct assumption. In some cases if you rotate a device now the tearing (when vsync is off) is vertical instead of horizontal, which is really disorienting if you're not used to it.
  - dspillett 5y ago
    But they do exist, as do other sub-pixel layouts (pentile, RGBG, ...). If you use sub-pixel rendering assuming RGB you are going to look worse on some devices (many Samsung phones, IIRC). Also, if you use sub-pixel tricks in static resources such as images (or your text renderer is not aware that the sub-pixels may not always be arranged horizontally) you are going to have colour halo effects when a device is rotated. Windows is doing that (optimising for horizontal RGB, when vertical RGB is the reality) right now on the screen I have rotated to portrait aspect. It isn't stark enough that I can see any colour halo at this dot pitch, in fact the effect is very subtle, but seen side-by-side text looks a little blury on that screen compared to the other screen (practically the same dot pitch, but landscape so actually is a horizontal RGB layout). Someone with better eyes (mine are somewhat shite) might find it more irritating that I do. I must get around to telling Windows to just use greyscale text trickery...
  - kuschku 5y ago
    I use one monitor in portrait mode, one in landscape. Something relatively common for devs.
- steerablesafe 5y ago
  Yes, it's more complicated, and parts of it might need hacks, as there are no standard way to get subpixel layout. That's a failure of those display APIs though, not the failure of the concept of subpixel-AA itself. > does it make correct gamma rendering more complex? switch to dark mode harder? Most text rendering is gamma-incorrect anyway, AFAIK, subpixel-AA or not. It doesn't make it more complex, just work in a linear colorspace either way.
d_tr 5y ago
Subpixel AA literally gets the colors wrong at the boundary, so calling grayscale AA a simplification is a bit too much IMO. Some people prefer subpixel AA and it might even be a matter of accessibility for others, so its existence is a good thing I guess, but it is not grayscale that makes any false assumptions.
- steerablesafe 5y ago
  Pixel boundaries on your display are imaginary, all you have are RGBRGB light sources next to each other. The pixel boundaries are determined by your left-most and right-most light sources on the display, so you have |RGB|RGB|..., but it really shouldn't affect how you render text in the middle of your screen. edit: > it is not grayscale that makes any false assumptions Grayscale assumes that those pixel boundaries are real, and they are relevant.
  - kevingadd 5y ago
    This assumes you actually have RGB light sources in that order. There are (were?) consumer displays with RGBW or other alternative arrangements out there, not to mention panels with a different color ordering. And if you rotate or invert the display, the ordering becomes different. An ordinary consumer will never understand what's going on here, so if your code assumes RGB subpixel rendering for text is always correct, it's just going to look ugly to them for no reason.
    - steerablesafe 5y ago
      I was assuming that to make a point. The actual subpixel order can either be retrieved by an appropriate API (if available) or be provided by the user (display settings). Point being, subpixels don't usually overlap on the same area, which is what's grayscale's assumption. I agree that if subpixel order is not known, then grayscale is a sane default.
      - user-the-name 5y ago
        If your stroke is 7 subpixels wide, it will be, for instance, RGBRGBR. That has three Rs, two Gs, and two Bs. That is 50% more red light than blue or green. That is tinted red, no matter how you look at it. Subpixel antialiasing does distort colours. That is just a physical fact. The only reason it works at all is that on average, it will even out to a uniform white. But in the details, it will not. Especially around straight vertical edges.

samwillis 5y ago

If text rendering hates you, an editable text renderer is 10x worse. Anyone who has spent any time working on contenteditable or any of the browser based rich text editors knows what a nightmare it is. The temptation to abandon all hope and start from scratch with a canvas element and build you own renderer and editor is strong. You start researching how to do it, maybe even create a quick prototype but quickly discover all the edge cases in this article and more. People who have spent significant parts of their career fixing all the inconsistencies between browsers and devices such as Marijn Haverbeke with ProseMirror (and CodeMirror) should get a Gallantry award for the work they have done.

jahnu 5y ago
It's pain all the way down على طول الطريق uʍop ʎɐʍ ǝɥʇ llɐ
- alpaca128 5y ago
  Maybe it's just on my side but the l's in the flipped "all" seem to be either displayed upright or not at the correct height. Which would only support the linked article.
  - saithir 5y ago
    For extra pain, you can go at the text above with your browser's devtools and change the font-family to something funny like Comic Sans MS. Turns out text rendering _really_ does hate you.
  - tialaramex 5y ago
    The flipped text is doing a trick where you pick things from Unicode that merely look like upside down Latin letters. Some of them deliberately are exactly that for whatever reason, some aren't. So the effect isn't exactly perfect and shouldn't be. There isn't actually a plain text way to say "for some reason render this upside down" because like, why.
    - 5y ago

EasyTiger_ 5y ago

Clickbait titles are getting worse and even more nonsensical

ChrisMarshallNY 5y ago
That’s the article title, and the article is over two years old, so I’m not sure it’s an effective data point for the diagnosis.
- kzrdude 5y ago
  It's kind of an off-putting title for a good article, to be honest.
  - ChrisMarshallNY 5y ago
    I agree. It is an excellent article. Text systems are weird. There's an entire book about strings, in Swift: https://flight.school/books/strings/ https://flight.school/books/strings/
blinkingled 5y ago
OTOH I would have never read an article on Text Rendering if it wasn't for a clickbait title :) - IOW totally justified for the good cause of making people more aware of obscure yet interesting topic they never cared about!

iqanq 5y ago

ascii using cleartype seems to work fine for me, I don't see the issue.

nyanpasu64 5y ago

Another Fun(tm) rendering bug: In Firefox, when a word is split across lines between two characters normally connected by a ligature, the ligature doesn't get disabled and the two characters rendered separately, but the ligature is sliced in half and rendered across lines: - https://bugzilla.mozilla.org/show_bug.cgi?id=479829 https://bugzilla.mozilla.org/show_bug.cgi?id=479829 - https://bug479829.bmoattachments.org/attachment.cgi?id=363733 https://bug479829.bmoattachments.org/attachment.cgi?id=36373...

chrismorgan 5y ago
The fun thing here is that as soon as I read Firefox, I knew it was going to be the split ligature issue. There are so few text rendering issues in Firefox, and that’s probably the only one most people will ever encounter.
- andjd 5y ago
  My reaction to this was how would this ever be a common issue? When would you naturally have a line break in the middle of a ligature. The screenshots show the answer: auto hyphenation. But at the point you're dropping a hyphen between the elements of a ligature, how do you not break up the ligature into two independent glyphs?
  - zerocrates 5y ago
    I assume the basic issue is that by the time they've decided how big the text is (and therefore if/where they need hyphenation), they've already decided to use the ligature. Dynamically deciding whether or not to use the ligature when its at the linebreak seems expensive... refusing to do a ligature in the presence of a soft hyphen and otherwise treating the ligature as a single unit that cannot be broken seems like the more tractable way out of the problem... but I'm sure I'm avoiding or unaware of some additional piece of complexity.
moffkalast 5y ago
There is something profoundly weird with text rendering in Firefox. Having used Chrome for years and then switched for a while I tried all the different antialiasing modes in the config but neither of them look the same as Chrome somehow, it's all just a tiny bit off and it's so unnerving. Also if you have an input box in html with a size value set to the number of chars you need, that value will be always too short in Firefox, so you have to set it to some multiple which then renders too long in all other browsers where it resolves correctly. I think it's been logged on bugzilla and closed as wontfix, as usual. Typical firefox development cycle.

DiabloD3 5y ago

AA is bad if you do not have a concept of how gamma works. If you have a program[1] that does not understand the difference between sRGB and Linear RGB, the color fringing is extremely nasty, especially on light-on-dark situations. If they don't get the gamma wrong, they get the blend mode wrong (cough Alacritty at one point cough) The fix, honestly, is moving to 200% resolution screens (such as 4k 24" replacing everyone's 1080p 24", or 2880p 27" replacing everyone's 1440p 27"), and using greyscale AA: fonts are now so big, pixelwise, that hinting doesn't screw up fonts, hand hinting is no longer relevant, and any given renderer has a lot of trouble screwing it up. Greyscale with wrong gamma and/or wrong blend mode isn't fatal, it is fatal with subpixel. 1: Such as ClearType on Windows, but not the modern DirectWrite engine. Win10 tried to improve ClearType to make it look more like DirectWrite, but only made its error less harsh. Early versions of Freetype that had subpixel rendering also did this wrong.

zamalek 5y ago
> such as 4k 24" replacing everyone's 1080p 24" The problem is the prevalence of 1080p. 1440p on 24" becomes 'retina' at 28" viewing distance (vs 37" for 1080p and 19" for 4k). Grayscale anti-aliasing at that pixel density is really good, gaining you a few inches of viewing distance. I would personally like to see something commonly available between 1440p and 4K (the jump in resolution is abnormally significant). If you've worked on a high refresh rate it's also really hard to drop down and, currently, it's still mostly a choice given the bandwidth and compute requirements. The difference between 60Hz and 144Hz is like the difference between 480p and 1080p, even for tasks like text editing. 60Hz is fucking awful.
GekkePrutser 5y ago
I run 24" @ 4K at 200% scaling and it's amazing. But 24" 4K is very hard to get now. All 4K screens I can buy here are 27" and up..
steerablesafe 5y ago
> Greyscale with wrong gamma and/or wrong blend mode isn't fatal, it is fatal with subpixel. I might not be fatal with black-on-white or white-on-black, but grayscale is pretty much still horrible with colored text and background.

Semaphor 5y ago

Both Chrome and FF seem to have fixed their text rendering with intersecting cursive glyphs since 2019 :)

black3r 5y ago
not on Linux.
- Semaphor 5y ago
  Ah, so maybe that was always only an issue on Linux, it’s fine on Windows.
  - Gankra 5y ago
    No it was a cross platform issue when I wrote the article. It's pretty fundamental to how most engines render text. That said, text rendering generally involves some amount of platform-specific APIs to get a "native" look and feel. I still see it on the latest Firefox nightly on MacOS. I know Windows DirectWrite handles the issue (which is why Edge handles this issue so well), so if the that's being used more it would probably help.

gjvc 5y ago

Excellent summary. Text rendering and content creation and layout (of which text is fundamental) are central to the creative experience on a computer. Anyone know any well-known (or otherwise) fora for discussing these kind of existential-level concepts?

aasasd 5y ago

Huh, this is not that story where the author, and possibly other people, spent over 1.5 years attempting to redo their text renderer/editor, and had to abandon the project in the end.

rainbowjelly 5y ago
Do you mean this [1]? It links to the referenced article too. [1] https://lord.io/text-editing-hates-you-too/ https://lord.io/text-editing-hates-you-too/
- aasasd 5y ago
  Yeah, that's it.

jfk13 5y ago

Previous discussion: https://news.ycombinator.com/item?id=21105625 https://news.ycombinator.com/item?id=21105625 (but well worth re-visiting from time to time).

HelloNurse 5y ago

Several of the initial definitions are brilliant (like defining emoji by their use of multiple colours), but some are misleading or even incorrect (for example, ligatures draw multiple consecutive scalars, but are made up of one or more glyphs; scripts are sets of scalars, not of glyphs).

perlgeek 5y ago

[2019] (still awesome!)

tomjonesey 5y ago

FrostKiwi 5y ago

Everyone is in the mood to write about text rendering today for some reason, love it. Great to see so many points paralleled like this article talking [1] about sub-pixel offsets being a challange and Nuklear's Wiki article talking [2] about snapping glyphs to an interger offset. [1] https://gankra.github.io/blah/text-hates-you/#subpixel-offsets-break-glyph-caches https://gankra.github.io/blah/text-hates-you/#subpixel-offse... [2] https://github.com/Immediate-Mode-UI/Nuklear/wiki/Complete-font-guide#pixel-snap https://github.com/Immediate-Mode-UI/Nuklear/wiki/Complete-f...

fjfaase 5y ago

Interesting read. I remember having to implement Unicode support and RTL in a graphic library (based on some version of InkScape, if I am not mistaken) that was code page. I implemented it using Uniscribe. The article 'Uniscribe: The Missing Documentation & Examples' was of great help implementing it. However, when I had to implement fallback fonts (for when the standard font does not contain the character you want to display and you want to get it from a different font) I got stuck because I discovered that at time (around 2015/2016) it was not implemented because MicroSoft had replaced Uniscribe by something new. There is also something interesting about the cursor moving through a miked LTR RTL text. It jumps over a character, meaning that it goes through different location depending on whether you move forward or backwards through the text, where forwards means that the cursor moves backwards on the screen when going through a bit of RTL text.

deleted 5y ago

[deleted]

The_O_King 5y ago

Oh this article is back! This is a shot in the dark, but perhaps someone could help me; I remember a link was posted at one point or another about font rendering as well, but from a design perspective about the considerations that need to be taken when designing a font, how glyphs are connected for different languages, etc. - it was presented quite beautifully, with many highlighted examples. Unfortunately all I remember from the site was that it had a green/teal theme to it :( and I haven't been able to find the link ever since Does anyone have any clue what I'm talking about? Pointers would be appreciated :)

LinAGKar 5y ago

In my experience, subpixel antialiasing works reasonably well for dark-on-light, but it looks terrible for light-on-dark.

sharikous 5y ago

Having different styles for elements in ligatures makes sense in some other situations too. E.g. you want to emphasise the accent on a letter when you are teaching the language, I found myself doing exactly that with Hebrew and punctuation, and I stumped upon this problem

korse 5y ago

I run a big CRT monitor with one terminal window and bitmap fonts. I've never had an error using this setup, except when something tries to use a character that isn't in my font and I get a �. This is rare. I've also programmed FPGAs to act as serial terminals and had zero problems perfectly displaying bitmap text. If you get something you can't perfectly display, chances are you don't need to display it so you mark it and throw it out (or you have a bitmap version handy). Due to these experiences, stuff like this seems like a major case of 'too much complexity'. Why is this sort of fancy text rendering so important (for a english speaking and writing person that can pretty much do all work and hobby projects in ASCII)?

layer8 5y ago
> (for a english speaking and writing person that can pretty much do all work and hobby projects in ASCII) Most people are not English-speaking/writing and expect “fancy” fonts to not be rendered in a crappy way. Also, the relative blurriness of your CRT alleviates some of the problem. The low-res, mostly latin-only font-rendering world of thirty years ago was certainly simpler.
fatbird 5y ago
"An english speaking person able to work entirely in ASCII" is a single use case that still leads to that complexity: we have emojis because people started drawing things with ascii characters. More recently, we have fonts for coding allowing for ligatures, and they're popular among a significant number of your fellow english speakers who could work entirely in ASCII. Even then, much of the complexity outlined in the article still appears when you consider variable width fonts--really, your use case is english user, using only ASCII in a monospaced font. Variable width fonts need kerning, and to accommodate changes in glyph size based on italic or bold variations. Also, English has ligatures like æ, so if you want to deal with older English texts you need them. And then what do you do if you're working in English but need to discuss other languages, even just common European ones with accents? So your use case is now english ASCII monospace user working who's basically just programming with their editor, and this is a very, very narrow use case considering the rest of English speaking/writing users who want to use computers in their own lives. Now multiply all the complexity I've sketched out for every language on Earth spoken/written by some community that would also like to use computers.

phkahler 5y ago

6.1 Fonts Can Contain SVG That whole section needs to go. Don't embrace any non-standard stuff. Fortunately support is poor, so let's hope Google doesn't add support for this in Chrome or it may become popular enough that everyone has to support it.

CryZe 5y ago
They just extended the COLR spec to COLRv1 which essentially is a whole new canvas API in fonts: https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md https://github.com/googlefonts/colr-gradients-spec/blob/main...
Gankra 5y ago
Ah ok! We'll be sure to drop looping support from Animated GIFs too, because that's also non-standard[0] and is just an extension Netscape 2.0 slapped on there. I regret to inform you the vast majority of the web is just Shit People Tried and that became popular enough for everyone else to support, with lots of hacks to make things interoperate better. [0]: https://en.wikipedia.org/wiki/GIF#Animated_GIF https://en.wikipedia.org/wiki/GIF#Animated_GIF

jancsika 5y ago

> 6.1 Fonts Can Contain SVG This is amazing-- it means someone can design a font where glyphs consist only of SVG elliptical arcs! Ooh even better-- the font designer could place the arcs in such a way that setting large-arc and sweep flags would generate different glyphs. If someone has not designed such a font in the year 2022 then what are the large-arc and sweep flags even for? How can we seriously continue calling this site Hacker News? Why isn't this very comment full of SVG arcs?!? Edit: OMG what about animating the large-arc and sweep flags in an SVG-based font? I want a transition that starts at war with Eastasia on a Monday and ends on war with Eurasia on a Tuesday. We have the technology

warent 5y ago

I built my business around font rendering! Shout out to Behdad https://en.wikipedia.org/wiki/Behdad_Esfahbod https://en.wikipedia.org/wiki/Behdad_Esfahbod a one of a kind man doing god's work. If you've seen text on a screen, you've seen Behdad's work. I've had the lucky opportunity to chat with him briefly and he personally helped me debug a text rendering problem. He's a great guy! Glyphs are registered, text is shaped, and everything is drawn via a ballet of various libraries, often with Pango and Cairo: https://pango.gnome.org/ https://pango.gnome.org/ https://docs.gtk.org/PangoCairo/ https://docs.gtk.org/PangoCairo/ By the way, if you think this is interesting, you might also be curious to read about how fonts are installed/registered on Unix systems. It is a rabbit hole involving a key piece of software on pretty much every computer in the world called Fontconfig (also by Behdad) https://en.wikipedia.org/wiki/Fontconfig https://en.wikipedia.org/wiki/Fontconfig Text and fonts are HARD. Give a hand to those who work tirelessly behind the scenes on this stuff for us. ( Shameless plug of my site https://fontpeek.com/ https://fontpeek.com/ )

bob1029 5y ago

Can confirm this is very hard to do. I was able to create my own 2d text rendering primitive from scratch (for fun), but it has the following "features": 1 font 4 font sizes 16 foreground colors 2 background colors Support for a generous subset of ASCII characters Text wrapping which succeeds as expected in ~50% of cases DPI "agnostic" The only thing that I could ever got any traction with was rasterizing every combination of font/size/color into some texture atlas and then using a dictionary of coordinates & dimensions around each for lookup & calculation. Clearly, this approach falls flat on its ass once you involve non-trivial requirements (i.e. beyond a subset of ASCII), or a variety of fonts/sizes/colors which create adverse combinatorics. That said, when you can reduce any problem space to composition of basic 2d images, things get really simple to think about.

andrewflnr 5y ago

On my Firefox/Fedora browser, the "tofu" glyph seems to have turned into... a goat? Cow? Is anyone else seeing this? Do I just have weird system fonts? How do I even research this? I guess it helps illustrate the article's point, anyway.