32 ms·

Text Rendering Hates You

542 points by robin_reala 7y ago

leni536 7y ago
Another pain point on text AA: Many renderers mix up colorspaces on antialiasing. For example freetype assumes a linear colorspace when calculating the antialiased bitmap but AFAIK both GTK and QT apply it directly on sRGB without any adjusting. The result is apparently thickened fonts when displayed black on white and thinned fonts when displayed white on black. Edit: Some background can be read on [0]. [0] https://www.freetype.org/freetype2/docs/text-rendering-general.html#background https://www.freetype.org/freetype2/docs/text-rendering-gener...
- enqk 7y ago
  I believe it's somewhat unavoidable as the fonts may also have co-evolved to work with renderers that work that way
  - leni536 7y ago
    Sure, that's what stem-thickening is meant to compensate in the cited article.
  - ahartmetz 7y ago
    Yes - fonts looked too thin and rather ugly when the color space "bug" was fixed in early Qt 5 (on Linux / more precisely, with FreeType glyph rendering) versions. The fix was reverted to fix the look of text.
- z3t4 7y ago
  With high density monitors on the rise we should get rid of LCD (RGB rainbows) anti alias as its really just a hack.
  - leni536 7y ago
    I strongly disagree, also the way the article describes subpixel antialiasing is not entirely accurate. The thing is the boundaries between pixels don't actually exist, it's just a convention so we can address individual pixels and subpixels within them. But these subpixels are not at the same position within the pixels and this needs to be taken into account for antialiasing. Also regarding hiDPI: I know that you just want to get rid of subpixel antialiasing but you really don't want to get rid of antialiasing in general. It's not really an issue with typefaces, but non-antialiased high-frequency patterns can easily generate unwanted Moiré patterns on you display regardless how high is your display resolution.
    - ken 7y ago
      It’s pretty much arbitrary what we as an industry have decided “text” means (and this has changed over the years), and what features it ought to support. It’s largely “what our technology easily supports today”. For example, most people expect antialiasing (i.e., subsampling across space) but we seem to have written off the idea of motion blur (i.e., subsampling across time), except in some games. It’s be technically more accurate to draw a quickly-dragged mouse cursor with a (correctly computed) blur, but that’s not generally easy to render today. And motion blur of moving subpixel antialiased text sounds like a nightmare right now, but with the right abstractions it might not be.
      - leni536 7y ago
        Motion blur is only "accurate" if you assume that the viewer's eyeballs remain still and don't follow the moving object. Having said that not blurring isn't accurate either on current LCDs when the viewer follows the object. This is what black frame insertion is meant to correct.
      - SpaceManiac 7y ago
        Antialiasing (nominally) makes text easier to read. Motion blur makes everything it's applied to harder to see.
    - floatboth 7y ago
      Pretty much no one wants to get rid of antialiasing in general. I use only grayscale antialiasing, even on LoDPI screens. It looks great. Subpixel adds bad color fringes.
  - vardump 7y ago
    Addressing subpixels according to their spatial location is no way a hack.
  - Const-me 7y ago
    New high-end PCs indeed use high DPI displays, but color LCD monitors are now used in cars, dishwashers and microwaves. These are not high-DPI, and they often lack CPU and GPU power to handle high DPI. Here's a library I've made for an embedded Linux device: https://github.com/Const-me/nanovg https://github.com/Const-me/nanovg At 5" 800x480, subpixel AA improved text a lot.
- jjgod 7y ago
  Qt does do gamma correction when it comes to text rendering.
  - ahartmetz 7y ago
    Maybe for blending, white on black text and things like that - after calculating shades the "wrong" way for compatibility with fonts' built-in expectations. See my other comment about that.
glandium 7y ago
Fun fact about subpixel antialiasing: at some point, Firefox was printing the subpixels when printing PDFs displayed with PDF.js. That looked awful. I'm actually not sure whether that was fixed, as I haven't printed in years (also, I have disabled subpixel AA for a while because of my dual monitor not in the same direction setup)
- sokoloff 7y ago
  I got some printed marketing material at a trade show last week. Screenshot of grey sub-pixel text, enlarged and printed in CMYK onto flyers. Obviously blurry and color-fringed; hard to believe anyone approved that artwork or finished product.
  - stallmanite 7y ago
    Perhaps it was an artistic choice? Doubtful depending on what the marketing material was for but I’ve seen interesting stuff along those lines. A good analogy would be how some people like the sound of “cheap” synthesizers.
- srbby 7y ago
  Probably because pdf.js is implemented using <canvas> so it's basically like printing screenshots of the PDF
  - SigmundA 7y ago
    They have been working on SVG backend for quite a while to get real vector printing, still not done.
    - leni536 7y ago
      I am not surprised, given the poor SVG support of Firefox (and browsers in general). Also there are gradient types that PDF supports but SVG doesn't. I am also not sure why they would need to go through SVG for printing.
enriquto 7y ago
One man's antialiasing is another mans blur. I, for one, prefer crisp bitmap fonts.
- amelius 7y ago
  You could use a font specifically designed to be displayed that way.
- jokoon 7y ago
  What is the best sans serif bitmap font?
  - thristian 7y ago
    Lucida Sans.
    - jokoon 7y ago
      that's not a bitmap font
      - thristian 7y ago
        Sure it is: -b&h-lucida-medium-r---14--75-75--*-iso10646-1
- zajio1am 7y ago
  I prefer rendering with strict grid-fitting, with crisp stems but antialiased arcs. Unfortunately, in current Linux, it does not work even with full hinting enabled by standard fontconfig settings, one have to set magic variable FREETYPE_PROPERTIES=truetype:interpreter-version=35 .
- chrisseaton 7y ago
  Where do you find bitmap fonts that are high resolution enough for modern displays?
  - 7y ago
frou_dh 7y ago
High-DPI (namely 200+ DPI, aka Retina) text rendering on desktop computers is one of the more impactful hardware developments for programmers in a while. When you're looking at text all day every day, having every single glyph take a massive step up in fidelity (4x the pixel budget!) is not to be sneezed at.
- seanmcdirmid 7y ago
  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
  - bloopernova 7y ago
    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.
    - seanmcdirmid 7y ago
      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.
    - ahartmetz 7y ago
      Edit: obviously that is only for the resolution... Try looking at any recent smartphone with an at least full-HD display ;) To appreciate just how many pixels there are and how many pixels per glyph, take a screenshot and look at it on a computer monitor. It's kind of surprising.
  - reaperducer 7y ago
    Want a bit of pixel shock? Find someone with an original iPhone. I fired mine up a few weeks ago and simply couldn't believe that we used to use screens that low resolution and blurry. My eyes have become spoiled.
amelius 7y ago
It seems that the term "subpixel" is overloaded. In one meaning the term refers to the RGB parts. In another meaning the result looks different when the text is shifted by less than a pixel, even on a monochrome screen.
- skrebbel 7y ago
  Yep, this one confused me too. But this article appears to use the term consistently for the first meaning.
- pekim 7y ago
  In the first case, I believe that it's normally referred to as "subpixel antialiasing". And in the second case, "subpixel positioning".
  - amelius 7y ago
    Yes, good point, but what would you call it if you'd apply both concepts at the same time?
    - mmmrk 7y ago
      Subpixel antialiasing plus subpixel positioning :) They are orthogonal concepts.
1wd 7y ago
"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.
- bfgeek 7y ago
  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.
- Kuinox 7y ago
  Looks like they changed things. The link [1] given is not working on firefox, while the website is telling me to use firefox. [1] : https://colorfonts.langustefonts.com/disco.html https://colorfonts.langustefonts.com/disco.html
- iggldiggl 7y ago
  I get the "awful" look in Firefox if I enable Webrender.
ttsda 7y ago
>3.2 Style Can Change Mid-Ligature >Here's what they look like in Chrome and Safari: Running 76.0.3809.132 here on Mac OS and it looks very different from the picture. Bug partially fixed? https://i.imgur.com/CcjATLO.png https://i.imgur.com/CcjATLO.png
- MatmaRex 7y ago
  It probably depends on the OS. I assume screenshots in the article are on Linux. On Windows it looks different still: https://i.imgur.com/ri2yUrR.png https://i.imgur.com/ri2yUrR.png
  - ttsda 7y ago
    The article has Safari and Edge screenshots through, so I would assume Windows was used
- jrochkind1 7y ago
  On the other hand, here's 3.1 on my MacOS Chrome, i don't think it's supposed to look like this: https://imgur.com/HLiFPIt https://imgur.com/HLiFPIt
sings 7y ago
> Synthetic bold: paint every glyph multiple times with a slight offset in your text-direction. Designers forgetting to include a bold version of their web fonts is one of my biggest bug bears. It always stands out, especially on Safari on iOS as you zoom in and out.
- jimbo1qaz 7y ago
  I think Chrome (PC/Android) implements synthetic bold by expanding the glyph outline, then drawing it with subpixel off. It's prettier than Firefox's "horizontal-only extrusion", but sometimes leads to funny artifacts at sharp corners.
  - jfk13 7y ago
    How Firefox implements synthetic-bold varies across different platforms, actually, depending on the features of the (platform-specific) font rendering backend it's using. It uses the paint-multiple-times-with-a-small-offset approach when the font backend doesn't seem to offer a "better" synthetic-bold option.
    - Gankro 7y ago
      Yeah the smearing approach is the only one that merits a callout from my position in the pipeline, because the other approaches are handled by your shaper or rasterizer, which are usually 3rd party libs that can be mostly regarded as black boxes.
- floatboth 7y ago
  > forgetting Or rather deliberately not including to decrease download size. Though OpenType variable fonts are a thing now. e.g. Inter https://rsms.me/inter/ https://rsms.me/inter/ has a variable version
  - sings 7y ago
    Maybe deliberate, but I don’t think it’s a good idea. This is an optimisation where the user actually sees the artefact/degradation. And that font would otherwise be used over the whole session. Excluding bold copy on the page or using system fonts in the design seem like better alternatives for saving bandwidth. Or appropriate use of the font-display property. Otherwise I see this as choosing custom fonts and only half implementing them for a design. And variable fonts still need two sets of outlines to interpolate between glyph weights, so they may not completely answer the problem.
likeclockwork 7y ago
For the color example they say "here's what they look like in Chrome and safari"... and show some horrible mess, yet I'm on Chrome and that isn't what I see at all? The text I see looks fine, although the font is different. https://imgur.com/a/5JZVZCB https://imgur.com/a/5JZVZCB
- thedufer 7y ago
  I wonder if it is partially OS-dependent? I'm also on Chrome, but see something closest to the Safari version.
hsivonen 7y ago
If it weren't for Windows, we could move on from TrueType outlines (.ttf) to CFF outlines (.otf). .otf works nicely on non-Microsoft rasterizers. It was terrible on XP. Now on Windows 10 it’s less terrible, but .otf fonts on Windows 10 using DirectWrite look bolder and blurrier than using FreeType, Apple, or Adobe rasterizers. If Microsoft adopted the Mac font rendering aesthetic and fixed their CFF rasterizer, we wouldn't need to worry about TrueType hinting anymore. But now, since your PDFs and Web fonts get viewed on Windows, you need to use TrueType outlines with Windows-friendly hinting even if you aren't using Windows yourself.
- thrower123 7y ago
  Someday, 90% of people won't be running Windows... It's been said for decades now, but it might happen some day.
  - otterley 7y ago
    If we consider smartphone browsers, that time has already come to pass!
    - zamadatix 7y ago
      Half sure, 90% no.
      - otterley 7y ago
        There are over 2.5 billion active Android devices (https://twitter.com/Android/status/1125822326183014401 https://twitter.com/Android/status/1125822326183014401). There were over 700 million active iPhones in 2017, likely more today (https://fortune.com/2017/03/06/apple-iphone-use-worldwide/ https://fortune.com/2017/03/06/apple-iphone-use-worldwide/). So conservatively there are over 3 billion smartphones. Microsoft claims there are over 1 billion Windows 10 installations (https://news.microsoft.com/bythenumbers/en/windowsdevices/ https://news.microsoft.com/bythenumbers/en/windowsdevices/) and over half are running Windows 10; so that means that less than 2 billion Windows installations are in existence. The numbers are pretty clear at this point.
koonsolo 7y ago
Some things are indeed way harder than they seem. Some others I came across: - time - indoor positioning
jchw 7y ago
Subpixel AA is basically just trading color resolution for spatial. It’s true that it’s not composable, but you can actually “fix” that by keeping it in 3x horizontal format as long as possible, then actually rendering to 1x with subpixel detail later. P.S.: because subpixel effectively gives you 3x horizontal resolution, it looks terrible to still fit to a pixel grid horizontally. Check the Anti-grain geometry article on font rendering for more cool font rendering bits, I recall it being very interesting.
jffhn 7y ago
>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.md https://github.com/jeffhain/jolikit/blob/master/README-BWD.m...
- tenaciousDaniel 7y ago
  > 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.
  - mmmrk 7y ago
    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.
dictum 7y ago
> Mercifully, subpixel has become less relevant over the years: retina displays really don't need it, and the subpixel layout on phones, prevents the trick from working (without major work). On newer versions of macos, subpixel-aa of text is disabled at the OS level by default. Speaking of mercy, I wish Apple had disabled it only on hidpi displays and chosen a longer deprecation window for normal displays. I prefer keeping displays at a distance slightly longer than my arm. This completely hides the slight blur of subpixel antialiasing. Now a 1440p has significantly degraded text rendering (even though other graphics look great) and if you want to use an external display, it must be 4K or 5K to not get a blurry, thin mess.
- stefanfisk 7y ago
  Have you tried `defaults write -g CGFontRenderingFontSmoothingDisabled -bool NO`? (also needs a reboot)
  - dictum 7y ago
    Yep, but some say it's gone from Catalina. I don't try betas. Can someone on 10.15 verify that this still works?
    - apfsx 7y ago
      It does work on 10.15 latest beta (10 as of writing).
      - dictum 7y ago
        Good to know, thanks. Hope it makes it to GM.
gravitas 7y ago
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. :)
- ainar-g 7y ago
  I am a partially vision-impaired man, and I really can't stand the dark-grey on light-grey texts that a lot of modern web pages have. They are essentially unreadable to me. In order to comfortably read this article, I had to go to Firefox's Style Editor and make the text actually black. And it is ironic that an article about text rendering uses such low-contrast and small-sized text.
  - jfk13 7y ago
    > In order to comfortably read this article, I had to go to Firefox's Style Editor and make the text actually black Does the Reader View in Firefox help here?
    - ainar-g 7y ago
      Completely forgot about it. Yes, it does improve readability for me.
  - ahuth 7y ago
    Background is white and the text is #333. Contrast ratio is 12.63:1, which isn’t bad at all. Can’t really fault the author here
- Gankro 7y ago
  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.
euske 7y ago
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 poor, but it's common in PDF. Caveat: Latin alphabets are rotated by 90 degree (as explained in OP), but for punctuations, simply rotating the glyph isn't enough because the center line is going to be slightly off. You need special glyphs for rotated punctuation. - Unlike Latin scripts, most Chinese and Japanese characters are free to break line at any point, but there are exceptions: contracted letters (e.g. ちょっ) cannot be split. So you'll end up with treating each letter as a separate word. (Contracted letters are treated as one word.)
- echelon 7y ago
  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.youtube.com/watch?v=kh9Kk_RHn8Q https://m.youtube.com/watch?v=kh9Kk_RHn8Q Japanese is a really fun language. If you've ever had an interest in learning it, I recommend it. Reading kanji is a joy in and of itself, because it has a pleasant inner logic that gets deeper the more you learn.
  - iamvik 7y ago
    geminated not germinated haha it's not a seed :p
    - labster 7y ago
      Now you’re just arguing seminantics.
  - earthboundkid 7y ago
commandlinefan 7y ago
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.
- raphlinus 7y ago
  I'm not fluent in any language (except maybe English), but this was my job on Android for about five years, and I still have my hand in. I got very good at being able to spot various forms of incorrect rendering, and of course called in the experts when needed. One of my favorite examples was Devanagari shaping. In the word ट्विटर (tvitar = Twitter), does the "i" matra shape before the "tv" it in the middle of it? In my sample, people accepted it either way (and you'll see both depending on font), but there are lots of examples where one is just wrong.
  - rk06 7y ago
    As "Twitter" is a foreign word.there is no set standard to it. If I were to write it, I would write "tv" first. And draw an extended variant of "I" to cover "tv" In text rendering, this translates to a custom ligature for an unexpected combo. I am not sure how feasible it is to add ligatures for every such combos In real life, as long as the reader "gets" it, they would assume that it is the right way to write it :)
- pcwalton 7y ago
  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 understanding the languages.
  - Gankro 7y ago
    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?
praptak 7y ago
> That said, if you take a screenshot of subpixel text you will absolutely be able to see the colors if you resize the image I once tried to see the subpixel rendering using the Microsoft's magnifying glass tool. Got disappointed - the tool just disabled subpixel rendering. Globally, not just the area being magnified.
mmmrk 7y ago
> 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 https://gankra.github.io/blah/text-hates-you/#aa-breaks-glyp... 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.
- floatboth 7y ago
  +1. Subpixel AA seemed quite necessary back in the day with Windows XP and tiny, precisely hinted Tahoma/Verdana/etc. These days, with bigger better bolder fonts, better renderers, and the departure from pixel-perfect stuff in favor of higher resolutions, subpixel is absolutely unnecessary. Even on LoDPI screens I turn it off (assign none to lcdfilter in fontconfig) because the color fringes are so ugly. I always notice them.
  - Dragory 7y ago
    Subpixel AA is absolutely not unnecessary these days. I've seen a few programs switch off from it recently (in favor of grayscale AA) and every time it's been noticably more blurry. For example, Discord had a bug that disabled it just a few weeks ago (which has been fixed since), and Twitch's redesign also disabled it in their desktop app (which is why I now use Twitch almost exclusively on Firefox). Both of these apps are based on electron/chromium though, so text rendering, even with grayscale AA, could be better in some other programs. Unless we completely abandon small font sizes or switch exclusively to high-dpi screens (will likely happen eventually, but we're not there yet), subpixel AA can look much sharper than grayscale AA if properly configured and you're not sensitive to the color fringes (personally, sitting at about an arm's length from my monitor, I don't notice them at all). And I'd rather not have text rendering quality suddenly downgraded on my existing peripherals before that happens.
dahart 7y ago
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 term, it was already established long before LCDs existed. AFAICT “Greyscale antialiasing” was made up only to differentiate regular antialiasing from LCD antialiasing.
- Diggsey 7y ago
  "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.
  - dahart 7y ago
    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.
    - fourthark 7y ago
      How does standard antialiasing involve subpixels - are you talking about retina or something? It applies alpha to pixels of whatever size right? What's the sub- part?
      - dahart 7y ago
        It’s common in both software and especially hardware to render at a higher resolution and then filter & downsample. The 2x2 or 3x3 or 4x4 etc pixels in the higher resolution that correspond to the 1 pixel at final resolution, those are called subpixels. For example, you can read about subpixels in descriptions of traditional aliasing as well as GPU antialiasing. https://en.m.wikipedia.org/wiki/Spatial_anti-aliasing https://en.m.wikipedia.org/wiki/Spatial_anti-aliasing https://en.m.wikipedia.org/wiki/Multisample_anti-aliasing https://en.m.wikipedia.org/wiki/Multisample_anti-aliasing The term subpixel is often referring to virtual pixels used to compute some final pixel value, as opposed to the LCD specific idea of a physical subpixel that’s red, green, or blue. Look around, for example, for discussions on subpixel resolution, subpixel positioning, subpixel animation, etc. Those are usually talking about the virtual kind used in traditional antialiasing, not the physical LCD subpixels.
eternalny1 7y ago
There are few things that scare me as a software engineer. Regex usually comes to mind first, but then I remember ... text rendering. Just reading Microsoft's Michael J Kaplan's blog (RIP) about Unicode, and how that plays into rendering, was daunting enough. But this article really points out how ridiculous it can get. No thanks, I'll stick to the easy stuff like my current project, Angular 8 / .Net Core, and let Firefox handle the tricky bits.
scraplab 7y ago
Once upon a time I wrote an automated newspaper layout/preview system in Cocoa, the rendering engine in MacOS. It was the only thing I could find that could do high quality text (ligatures, OpenType fonts, etc.), had native CMYK support, and could produce a print ready PDF or JPEG preview in milliseconds. I can’t open source the code, but if anyone ever needs to embark on something similar I’d be happy to share what I learnt.
deleted 7y ago
[deleted]
lostgame 7y ago
I miss non-AA’d text. Like PalmOS or Windows 95. Gotta love the sharpness of it somehow.
- cosmotic 7y ago
  I agree; I disable antialiasing to the best degree that I can when I code. This is not possible on Retina displays on MacOS though because they render at a higher resolution then down-sample. I was pretty disappointed the original article didn't talk much about hinting. Even old operating systems did a great job at type hinting to align glyphs to pixels (even when antialiasing is on). "Modern" operating systems (especially MacOS after Mavericks) assume retina and throw hinting to the wind; the consequence is pervasive blurry text even on retina displays.
  - oofabz 7y ago
    I like sharp, pixely text too but I don't like the color fringing you get on LCDs when you disable subpixel antialiasing. I wish I could get a display without this consistent chromatic abberation. One way to accomplish this would be to alternate subpixel layout from one pixel to the next. For example: RGBBGR BGRRGB Then the errors in color would cancel out, much like in serpentine dithering. You could do the same with a Pentile pixel layout like this: RGGR BWWB BWWB RGGR Either way, instead of seeing color fringing, I imagine it would give a grainy appearance similar to what dithering looks like.
privethedge 7y ago
> If you're in Safari or Edge, this might still look ok! If you're in Firefox or Chrome, it looks awful, like this: https://gankra.github.io/blah/text-hates-you/transparent-cursive.png https://gankra.github.io/blah/text-hates-you/transparent-cur... It doesn't look awful in Firefox, it looks perfect (it's version 26 of Firefox though.) This is what I see https://i.imgur.com/sjvqycv.png https://i.imgur.com/sjvqycv.png
- kitten_mittens_ 7y ago
  Mobile Safari is giving me the color stacking in your second link.
malicioususer11 7y ago
no it dorsnt. it hates you. :)
einpoklum 7y ago
This is a nice intuitive introduction for the naive. Of course - there is more. @euske explains some extra trouble for CJK. There is also the hell of _direction_ - RTL vs LTR text on the same line. There is a complex bidirectional algorithm that's part of the Unicode standard [1], and it involves breaks up text into runs of RTL and LTR text - but it's not at all trivial, since many characters are actually neutral, like punctuation marks. What's more, Unicode has a lot of control characters, that don't get rendered into glyphs but affect text rendering. These can be pretty tame, like space and non-breaking space - but some are rather nastly, like pushing and popping a stack of RTL-vs-LTR state (yes, it nests). [1] : http://www.unicode.org/reports/tr9/ http://www.unicode.org/reports/tr9/
TazeTSchnitzel 7y ago
That article links to this page about what a massive hack ClearType (Microsoft's subpixel anti-aliasing in Windows) is and I love it: http://rastertragedy.com/RTRCh4.htm#Sec1 http://rastertragedy.com/RTRCh4.htm#Sec1
- yesenadam 7y ago
  Wow, that's an amazing (and beautifully designed) website, thank you!
joe_the_user 7y ago
The other comments about the details rendering are great and an example of how much depth of knowledge you can find on HN (and all this is now well beyond my experience). What I'd be curious about here, though, is what this says about large scale software engineering. Text rendering has to be one of the most common activities within a large number of computer program sorts and I know pieces of the text rendering process are common examples in texts on object oriented programming, indeed the different of rendering processes seem to suggest objects and interface readily. Yet the standard pipleline the author describes seems leakier than anything I saw twenty years when I dealt with such issues - nothing is solved on the software engineering side, the mess just grows. Obviously, this is a product of adding new languages and new display models to the text rendering process, as well as standardizing the process so it accommodated different font approaches and etc. But object orientation as well as related models promised, some time in the past, something akin to "encapsulate the process and adding complexity will be easier". Object oriented programming has lost almost all luster but what alternatives? Could the pipeline be less leaky in functional programming or something similar or something different. It just makes me curious.
- bobbylarrybobby 7y ago
  Across all coding paradigms, it is always good to abstract at the correct level and to modularize as much as possible (really these are two sides of the same coin). The leaky nature of text rendering means that the only level you can really abstract at is the topmost level, and you’re left simply covering every imaginable case individually. Not sure if that can be solved by a programming paradigm.
  - joe_the_user 7y ago
    But is text rendering "inherently leaky"? Or more leaky than large scale accounting data or etc? At that rate, it seems like just about any messy, multilevel problem can be taken as inherently leaky and not something design paradigms can make easier. Maybe the solution is, "there is no solution" but as an optimist, it's hard for me to accept that. (And yeah, I should have said "design paradigm", not programming paradigm).
jimbo1qaz 7y ago
Why do both Windows and FreeType "faux italic" tilt the font too much for my liking? And why is the "point of zero tilt" at the baseline rather than 25-50% of the way up? This makes faux-italic text appear to be too far to the right. I feel like changing these 2 would make faux italic much less obtrusive.
tripzilch 7y ago
Really fascinating read. It reminded me of Tom Scott's video on Numberphile, about time zones: https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY Maybe it's the way Tom presents it, but I do get the distinct impression that (fully) dealing with time zones is an even more maddening incomprehensible quagmire of a task than rendering text as laid out in this article.

542 points by robin_reala 7y ago

Another pain point on text AA: Many renderers mix up colorspaces on antialiasing. For example freetype assumes a linear colorspace when calculating the antialiased bitmap but AFAIK both GTK and QT apply it directly on sRGB without any adjusting. The result is apparently thickened fonts when displayed black on white and thinned fonts when displayed white on black. Edit: Some background can be read on [0]. [0] https://www.freetype.org/freetype2/docs/text-rendering-general.html#background https://www.freetype.org/freetype2/docs/text-rendering-gener...

enqk 7y ago
I believe it's somewhat unavoidable as the fonts may also have co-evolved to work with renderers that work that way
- leni536 7y ago
  Sure, that's what stem-thickening is meant to compensate in the cited article.
- ahartmetz 7y ago
  Yes - fonts looked too thin and rather ugly when the color space "bug" was fixed in early Qt 5 (on Linux / more precisely, with FreeType glyph rendering) versions. The fix was reverted to fix the look of text.
z3t4 7y ago
With high density monitors on the rise we should get rid of LCD (RGB rainbows) anti alias as its really just a hack.
- leni536 7y ago
  I strongly disagree, also the way the article describes subpixel antialiasing is not entirely accurate. The thing is the boundaries between pixels don't actually exist, it's just a convention so we can address individual pixels and subpixels within them. But these subpixels are not at the same position within the pixels and this needs to be taken into account for antialiasing. Also regarding hiDPI: I know that you just want to get rid of subpixel antialiasing but you really don't want to get rid of antialiasing in general. It's not really an issue with typefaces, but non-antialiased high-frequency patterns can easily generate unwanted Moiré patterns on you display regardless how high is your display resolution.
  - ken 7y ago
    It’s pretty much arbitrary what we as an industry have decided “text” means (and this has changed over the years), and what features it ought to support. It’s largely “what our technology easily supports today”. For example, most people expect antialiasing (i.e., subsampling across space) but we seem to have written off the idea of motion blur (i.e., subsampling across time), except in some games. It’s be technically more accurate to draw a quickly-dragged mouse cursor with a (correctly computed) blur, but that’s not generally easy to render today. And motion blur of moving subpixel antialiased text sounds like a nightmare right now, but with the right abstractions it might not be.
    - leni536 7y ago
      Motion blur is only "accurate" if you assume that the viewer's eyeballs remain still and don't follow the moving object. Having said that not blurring isn't accurate either on current LCDs when the viewer follows the object. This is what black frame insertion is meant to correct.
    - SpaceManiac 7y ago
      Antialiasing (nominally) makes text easier to read. Motion blur makes everything it's applied to harder to see.
  - floatboth 7y ago
    Pretty much no one wants to get rid of antialiasing in general. I use only grayscale antialiasing, even on LoDPI screens. It looks great. Subpixel adds bad color fringes.
- vardump 7y ago
  Addressing subpixels according to their spatial location is no way a hack.
- Const-me 7y ago
  New high-end PCs indeed use high DPI displays, but color LCD monitors are now used in cars, dishwashers and microwaves. These are not high-DPI, and they often lack CPU and GPU power to handle high DPI. Here's a library I've made for an embedded Linux device: https://github.com/Const-me/nanovg https://github.com/Const-me/nanovg At 5" 800x480, subpixel AA improved text a lot.
jjgod 7y ago
Qt does do gamma correction when it comes to text rendering.
- ahartmetz 7y ago
  Maybe for blending, white on black text and things like that - after calculating shades the "wrong" way for compatibility with fonts' built-in expectations. See my other comment about that.

glandium 7y ago

Fun fact about subpixel antialiasing: at some point, Firefox was printing the subpixels when printing PDFs displayed with PDF.js. That looked awful. I'm actually not sure whether that was fixed, as I haven't printed in years (also, I have disabled subpixel AA for a while because of my dual monitor not in the same direction setup)

sokoloff 7y ago
I got some printed marketing material at a trade show last week. Screenshot of grey sub-pixel text, enlarged and printed in CMYK onto flyers. Obviously blurry and color-fringed; hard to believe anyone approved that artwork or finished product.
- stallmanite 7y ago
  Perhaps it was an artistic choice? Doubtful depending on what the marketing material was for but I’ve seen interesting stuff along those lines. A good analogy would be how some people like the sound of “cheap” synthesizers.
srbby 7y ago
Probably because pdf.js is implemented using <canvas> so it's basically like printing screenshots of the PDF
- SigmundA 7y ago
  They have been working on SVG backend for quite a while to get real vector printing, still not done.
  - leni536 7y ago
    I am not surprised, given the poor SVG support of Firefox (and browsers in general). Also there are gradient types that PDF supports but SVG doesn't. I am also not sure why they would need to go through SVG for printing.

enriquto 7y ago

One man's antialiasing is another mans blur. I, for one, prefer crisp bitmap fonts.

amelius 7y ago
You could use a font specifically designed to be displayed that way.
jokoon 7y ago
What is the best sans serif bitmap font?
- thristian 7y ago
  Lucida Sans.
  - jokoon 7y ago
    that's not a bitmap font
    - thristian 7y ago
      Sure it is: -b&h-lucida-medium-r---14--75-75--*-iso10646-1
zajio1am 7y ago
I prefer rendering with strict grid-fitting, with crisp stems but antialiased arcs. Unfortunately, in current Linux, it does not work even with full hinting enabled by standard fontconfig settings, one have to set magic variable FREETYPE_PROPERTIES=truetype:interpreter-version=35 .
chrisseaton 7y ago
Where do you find bitmap fonts that are high resolution enough for modern displays?
- 7y ago

frou_dh 7y ago

High-DPI (namely 200+ DPI, aka Retina) text rendering on desktop computers is one of the more impactful hardware developments for programmers in a while. When you're looking at text all day every day, having every single glyph take a massive step up in fidelity (4x the pixel budget!) is not to be sneezed at.

seanmcdirmid 7y ago
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
- bloopernova 7y ago
  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.
  - seanmcdirmid 7y ago
    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.
  - ahartmetz 7y ago
    Edit: obviously that is only for the resolution... Try looking at any recent smartphone with an at least full-HD display ;) To appreciate just how many pixels there are and how many pixels per glyph, take a screenshot and look at it on a computer monitor. It's kind of surprising.
- reaperducer 7y ago
  Want a bit of pixel shock? Find someone with an original iPhone. I fired mine up a few weeks ago and simply couldn't believe that we used to use screens that low resolution and blurry. My eyes have become spoiled.

amelius 7y ago

It seems that the term "subpixel" is overloaded. In one meaning the term refers to the RGB parts. In another meaning the result looks different when the text is shifted by less than a pixel, even on a monochrome screen.

skrebbel 7y ago
Yep, this one confused me too. But this article appears to use the term consistently for the first meaning.
pekim 7y ago
In the first case, I believe that it's normally referred to as "subpixel antialiasing". And in the second case, "subpixel positioning".
- amelius 7y ago
  Yes, good point, but what would you call it if you'd apply both concepts at the same time?
  - mmmrk 7y ago
    Subpixel antialiasing plus subpixel positioning :) They are orthogonal concepts.

1wd 7y ago

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

bfgeek 7y ago
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.
Kuinox 7y ago
Looks like they changed things. The link [1] given is not working on firefox, while the website is telling me to use firefox. [1] : https://colorfonts.langustefonts.com/disco.html https://colorfonts.langustefonts.com/disco.html
iggldiggl 7y ago
I get the "awful" look in Firefox if I enable Webrender.

ttsda 7y ago

>3.2 Style Can Change Mid-Ligature >Here's what they look like in Chrome and Safari: Running 76.0.3809.132 here on Mac OS and it looks very different from the picture. Bug partially fixed? https://i.imgur.com/CcjATLO.png https://i.imgur.com/CcjATLO.png

MatmaRex 7y ago
It probably depends on the OS. I assume screenshots in the article are on Linux. On Windows it looks different still: https://i.imgur.com/ri2yUrR.png https://i.imgur.com/ri2yUrR.png
- ttsda 7y ago
  The article has Safari and Edge screenshots through, so I would assume Windows was used
jrochkind1 7y ago
On the other hand, here's 3.1 on my MacOS Chrome, i don't think it's supposed to look like this: https://imgur.com/HLiFPIt https://imgur.com/HLiFPIt

sings 7y ago

> Synthetic bold: paint every glyph multiple times with a slight offset in your text-direction. Designers forgetting to include a bold version of their web fonts is one of my biggest bug bears. It always stands out, especially on Safari on iOS as you zoom in and out.

jimbo1qaz 7y ago
I think Chrome (PC/Android) implements synthetic bold by expanding the glyph outline, then drawing it with subpixel off. It's prettier than Firefox's "horizontal-only extrusion", but sometimes leads to funny artifacts at sharp corners.
- jfk13 7y ago
  How Firefox implements synthetic-bold varies across different platforms, actually, depending on the features of the (platform-specific) font rendering backend it's using. It uses the paint-multiple-times-with-a-small-offset approach when the font backend doesn't seem to offer a "better" synthetic-bold option.
  - Gankro 7y ago
    Yeah the smearing approach is the only one that merits a callout from my position in the pipeline, because the other approaches are handled by your shaper or rasterizer, which are usually 3rd party libs that can be mostly regarded as black boxes.
floatboth 7y ago
> forgetting Or rather deliberately not including to decrease download size. Though OpenType variable fonts are a thing now. e.g. Inter https://rsms.me/inter/ https://rsms.me/inter/ has a variable version
- sings 7y ago
  Maybe deliberate, but I don’t think it’s a good idea. This is an optimisation where the user actually sees the artefact/degradation. And that font would otherwise be used over the whole session. Excluding bold copy on the page or using system fonts in the design seem like better alternatives for saving bandwidth. Or appropriate use of the font-display property. Otherwise I see this as choosing custom fonts and only half implementing them for a design. And variable fonts still need two sets of outlines to interpolate between glyph weights, so they may not completely answer the problem.

likeclockwork 7y ago

For the color example they say "here's what they look like in Chrome and safari"... and show some horrible mess, yet I'm on Chrome and that isn't what I see at all? The text I see looks fine, although the font is different. https://imgur.com/a/5JZVZCB https://imgur.com/a/5JZVZCB

thedufer 7y ago
I wonder if it is partially OS-dependent? I'm also on Chrome, but see something closest to the Safari version.

hsivonen 7y ago

If it weren't for Windows, we could move on from TrueType outlines (.ttf) to CFF outlines (.otf). .otf works nicely on non-Microsoft rasterizers. It was terrible on XP. Now on Windows 10 it’s less terrible, but .otf fonts on Windows 10 using DirectWrite look bolder and blurrier than using FreeType, Apple, or Adobe rasterizers. If Microsoft adopted the Mac font rendering aesthetic and fixed their CFF rasterizer, we wouldn't need to worry about TrueType hinting anymore. But now, since your PDFs and Web fonts get viewed on Windows, you need to use TrueType outlines with Windows-friendly hinting even if you aren't using Windows yourself.

thrower123 7y ago
Someday, 90% of people won't be running Windows... It's been said for decades now, but it might happen some day.
- otterley 7y ago
  If we consider smartphone browsers, that time has already come to pass!
  - zamadatix 7y ago
    Half sure, 90% no.
    - otterley 7y ago
      There are over 2.5 billion active Android devices (https://twitter.com/Android/status/1125822326183014401 https://twitter.com/Android/status/1125822326183014401). There were over 700 million active iPhones in 2017, likely more today (https://fortune.com/2017/03/06/apple-iphone-use-worldwide/ https://fortune.com/2017/03/06/apple-iphone-use-worldwide/). So conservatively there are over 3 billion smartphones. Microsoft claims there are over 1 billion Windows 10 installations (https://news.microsoft.com/bythenumbers/en/windowsdevices/ https://news.microsoft.com/bythenumbers/en/windowsdevices/) and over half are running Windows 10; so that means that less than 2 billion Windows installations are in existence. The numbers are pretty clear at this point.

koonsolo 7y ago

Some things are indeed way harder than they seem. Some others I came across: - time - indoor positioning

jchw 7y ago

Subpixel AA is basically just trading color resolution for spatial. It’s true that it’s not composable, but you can actually “fix” that by keeping it in 3x horizontal format as long as possible, then actually rendering to 1x with subpixel detail later. P.S.: because subpixel effectively gives you 3x horizontal resolution, it looks terrible to still fit to a pixel grid horizontally. Check the Anti-grain geometry article on font rendering for more cool font rendering bits, I recall it being very interesting.

jffhn 7y ago

>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.md https://github.com/jeffhain/jolikit/blob/master/README-BWD.m...

tenaciousDaniel 7y ago
> 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.
- mmmrk 7y ago
  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.

dictum 7y ago

> Mercifully, subpixel has become less relevant over the years: retina displays really don't need it, and the subpixel layout on phones, prevents the trick from working (without major work). On newer versions of macos, subpixel-aa of text is disabled at the OS level by default. Speaking of mercy, I wish Apple had disabled it only on hidpi displays and chosen a longer deprecation window for normal displays. I prefer keeping displays at a distance slightly longer than my arm. This completely hides the slight blur of subpixel antialiasing. Now a 1440p has significantly degraded text rendering (even though other graphics look great) and if you want to use an external display, it must be 4K or 5K to not get a blurry, thin mess.

stefanfisk 7y ago
Have you tried `defaults write -g CGFontRenderingFontSmoothingDisabled -bool NO`? (also needs a reboot)
- dictum 7y ago
  Yep, but some say it's gone from Catalina. I don't try betas. Can someone on 10.15 verify that this still works?
  - apfsx 7y ago
    It does work on 10.15 latest beta (10 as of writing).
    - dictum 7y ago
      Good to know, thanks. Hope it makes it to GM.

gravitas 7y ago

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

ainar-g 7y ago
I am a partially vision-impaired man, and I really can't stand the dark-grey on light-grey texts that a lot of modern web pages have. They are essentially unreadable to me. In order to comfortably read this article, I had to go to Firefox's Style Editor and make the text actually black. And it is ironic that an article about text rendering uses such low-contrast and small-sized text.
- jfk13 7y ago
  > In order to comfortably read this article, I had to go to Firefox's Style Editor and make the text actually black Does the Reader View in Firefox help here?
  - ainar-g 7y ago
    Completely forgot about it. Yes, it does improve readability for me.
- ahuth 7y ago
  Background is white and the text is #333. Contrast ratio is 12.63:1, which isn’t bad at all. Can’t really fault the author here
Gankro 7y ago
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.

euske 7y ago

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 poor, but it's common in PDF. Caveat: Latin alphabets are rotated by 90 degree (as explained in OP), but for punctuations, simply rotating the glyph isn't enough because the center line is going to be slightly off. You need special glyphs for rotated punctuation. - Unlike Latin scripts, most Chinese and Japanese characters are free to break line at any point, but there are exceptions: contracted letters (e.g. ちょっ) cannot be split. So you'll end up with treating each letter as a separate word. (Contracted letters are treated as one word.)

echelon 7y ago
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.youtube.com/watch?v=kh9Kk_RHn8Q https://m.youtube.com/watch?v=kh9Kk_RHn8Q Japanese is a really fun language. If you've ever had an interest in learning it, I recommend it. Reading kanji is a joy in and of itself, because it has a pleasant inner logic that gets deeper the more you learn.
- iamvik 7y ago
  geminated not germinated haha it's not a seed :p
  - labster 7y ago
    Now you’re just arguing seminantics.
- earthboundkid 7y ago

commandlinefan 7y ago

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.

raphlinus 7y ago
I'm not fluent in any language (except maybe English), but this was my job on Android for about five years, and I still have my hand in. I got very good at being able to spot various forms of incorrect rendering, and of course called in the experts when needed. One of my favorite examples was Devanagari shaping. In the word ट्विटर (tvitar = Twitter), does the "i" matra shape before the "tv" it in the middle of it? In my sample, people accepted it either way (and you'll see both depending on font), but there are lots of examples where one is just wrong.
- rk06 7y ago
  As "Twitter" is a foreign word.there is no set standard to it. If I were to write it, I would write "tv" first. And draw an extended variant of "I" to cover "tv" In text rendering, this translates to a custom ligature for an unexpected combo. I am not sure how feasible it is to add ligatures for every such combos In real life, as long as the reader "gets" it, they would assume that it is the right way to write it :)
pcwalton 7y ago
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 understanding the languages.
- Gankro 7y ago
  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?

praptak 7y ago

> That said, if you take a screenshot of subpixel text you will absolutely be able to see the colors if you resize the image I once tried to see the subpixel rendering using the Microsoft's magnifying glass tool. Got disappointed - the tool just disabled subpixel rendering. Globally, not just the area being magnified.

mmmrk 7y ago

> 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 https://gankra.github.io/blah/text-hates-you/#aa-breaks-glyp... 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.

floatboth 7y ago
+1. Subpixel AA seemed quite necessary back in the day with Windows XP and tiny, precisely hinted Tahoma/Verdana/etc. These days, with bigger better bolder fonts, better renderers, and the departure from pixel-perfect stuff in favor of higher resolutions, subpixel is absolutely unnecessary. Even on LoDPI screens I turn it off (assign none to lcdfilter in fontconfig) because the color fringes are so ugly. I always notice them.
- Dragory 7y ago
  Subpixel AA is absolutely not unnecessary these days. I've seen a few programs switch off from it recently (in favor of grayscale AA) and every time it's been noticably more blurry. For example, Discord had a bug that disabled it just a few weeks ago (which has been fixed since), and Twitch's redesign also disabled it in their desktop app (which is why I now use Twitch almost exclusively on Firefox). Both of these apps are based on electron/chromium though, so text rendering, even with grayscale AA, could be better in some other programs. Unless we completely abandon small font sizes or switch exclusively to high-dpi screens (will likely happen eventually, but we're not there yet), subpixel AA can look much sharper than grayscale AA if properly configured and you're not sensitive to the color fringes (personally, sitting at about an arm's length from my monitor, I don't notice them at all). And I'd rather not have text rendering quality suddenly downgraded on my existing peripherals before that happens.

dahart 7y ago

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 term, it was already established long before LCDs existed. AFAICT “Greyscale antialiasing” was made up only to differentiate regular antialiasing from LCD antialiasing.

Diggsey 7y ago
"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.
- dahart 7y ago
  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.
  - fourthark 7y ago
    How does standard antialiasing involve subpixels - are you talking about retina or something? It applies alpha to pixels of whatever size right? What's the sub- part?
    - dahart 7y ago
      It’s common in both software and especially hardware to render at a higher resolution and then filter & downsample. The 2x2 or 3x3 or 4x4 etc pixels in the higher resolution that correspond to the 1 pixel at final resolution, those are called subpixels. For example, you can read about subpixels in descriptions of traditional aliasing as well as GPU antialiasing. https://en.m.wikipedia.org/wiki/Spatial_anti-aliasing https://en.m.wikipedia.org/wiki/Spatial_anti-aliasing https://en.m.wikipedia.org/wiki/Multisample_anti-aliasing https://en.m.wikipedia.org/wiki/Multisample_anti-aliasing The term subpixel is often referring to virtual pixels used to compute some final pixel value, as opposed to the LCD specific idea of a physical subpixel that’s red, green, or blue. Look around, for example, for discussions on subpixel resolution, subpixel positioning, subpixel animation, etc. Those are usually talking about the virtual kind used in traditional antialiasing, not the physical LCD subpixels.

eternalny1 7y ago

There are few things that scare me as a software engineer. Regex usually comes to mind first, but then I remember ... text rendering. Just reading Microsoft's Michael J Kaplan's blog (RIP) about Unicode, and how that plays into rendering, was daunting enough. But this article really points out how ridiculous it can get. No thanks, I'll stick to the easy stuff like my current project, Angular 8 / .Net Core, and let Firefox handle the tricky bits.

scraplab 7y ago

Once upon a time I wrote an automated newspaper layout/preview system in Cocoa, the rendering engine in MacOS. It was the only thing I could find that could do high quality text (ligatures, OpenType fonts, etc.), had native CMYK support, and could produce a print ready PDF or JPEG preview in milliseconds. I can’t open source the code, but if anyone ever needs to embark on something similar I’d be happy to share what I learnt.

deleted 7y ago

[deleted]

lostgame 7y ago

I miss non-AA’d text. Like PalmOS or Windows 95. Gotta love the sharpness of it somehow.

cosmotic 7y ago
I agree; I disable antialiasing to the best degree that I can when I code. This is not possible on Retina displays on MacOS though because they render at a higher resolution then down-sample. I was pretty disappointed the original article didn't talk much about hinting. Even old operating systems did a great job at type hinting to align glyphs to pixels (even when antialiasing is on). "Modern" operating systems (especially MacOS after Mavericks) assume retina and throw hinting to the wind; the consequence is pervasive blurry text even on retina displays.
- oofabz 7y ago
  I like sharp, pixely text too but I don't like the color fringing you get on LCDs when you disable subpixel antialiasing. I wish I could get a display without this consistent chromatic abberation. One way to accomplish this would be to alternate subpixel layout from one pixel to the next. For example: RGBBGR BGRRGB Then the errors in color would cancel out, much like in serpentine dithering. You could do the same with a Pentile pixel layout like this: RGGR BWWB BWWB RGGR Either way, instead of seeing color fringing, I imagine it would give a grainy appearance similar to what dithering looks like.

privethedge 7y ago

> If you're in Safari or Edge, this might still look ok! If you're in Firefox or Chrome, it looks awful, like this: https://gankra.github.io/blah/text-hates-you/transparent-cursive.png https://gankra.github.io/blah/text-hates-you/transparent-cur... It doesn't look awful in Firefox, it looks perfect (it's version 26 of Firefox though.) This is what I see https://i.imgur.com/sjvqycv.png https://i.imgur.com/sjvqycv.png

kitten_mittens_ 7y ago
Mobile Safari is giving me the color stacking in your second link.

malicioususer11 7y ago

no it dorsnt. it hates you. :)

einpoklum 7y ago

This is a nice intuitive introduction for the naive. Of course - there is more. @euske explains some extra trouble for CJK. There is also the hell of _direction_ - RTL vs LTR text on the same line. There is a complex bidirectional algorithm that's part of the Unicode standard [1], and it involves breaks up text into runs of RTL and LTR text - but it's not at all trivial, since many characters are actually neutral, like punctuation marks. What's more, Unicode has a lot of control characters, that don't get rendered into glyphs but affect text rendering. These can be pretty tame, like space and non-breaking space - but some are rather nastly, like pushing and popping a stack of RTL-vs-LTR state (yes, it nests). [1] : http://www.unicode.org/reports/tr9/ http://www.unicode.org/reports/tr9/

TazeTSchnitzel 7y ago

That article links to this page about what a massive hack ClearType (Microsoft's subpixel anti-aliasing in Windows) is and I love it: http://rastertragedy.com/RTRCh4.htm#Sec1 http://rastertragedy.com/RTRCh4.htm#Sec1

yesenadam 7y ago
Wow, that's an amazing (and beautifully designed) website, thank you!

joe_the_user 7y ago

The other comments about the details rendering are great and an example of how much depth of knowledge you can find on HN (and all this is now well beyond my experience). What I'd be curious about here, though, is what this says about large scale software engineering. Text rendering has to be one of the most common activities within a large number of computer program sorts and I know pieces of the text rendering process are common examples in texts on object oriented programming, indeed the different of rendering processes seem to suggest objects and interface readily. Yet the standard pipleline the author describes seems leakier than anything I saw twenty years when I dealt with such issues - nothing is solved on the software engineering side, the mess just grows. Obviously, this is a product of adding new languages and new display models to the text rendering process, as well as standardizing the process so it accommodated different font approaches and etc. But object orientation as well as related models promised, some time in the past, something akin to "encapsulate the process and adding complexity will be easier". Object oriented programming has lost almost all luster but what alternatives? Could the pipeline be less leaky in functional programming or something similar or something different. It just makes me curious.

bobbylarrybobby 7y ago
Across all coding paradigms, it is always good to abstract at the correct level and to modularize as much as possible (really these are two sides of the same coin). The leaky nature of text rendering means that the only level you can really abstract at is the topmost level, and you’re left simply covering every imaginable case individually. Not sure if that can be solved by a programming paradigm.
- joe_the_user 7y ago
  But is text rendering "inherently leaky"? Or more leaky than large scale accounting data or etc? At that rate, it seems like just about any messy, multilevel problem can be taken as inherently leaky and not something design paradigms can make easier. Maybe the solution is, "there is no solution" but as an optimist, it's hard for me to accept that. (And yeah, I should have said "design paradigm", not programming paradigm).

jimbo1qaz 7y ago

Why do both Windows and FreeType "faux italic" tilt the font too much for my liking? And why is the "point of zero tilt" at the baseline rather than 25-50% of the way up? This makes faux-italic text appear to be too far to the right. I feel like changing these 2 would make faux italic much less obtrusive.

tripzilch 7y ago

Really fascinating read. It reminded me of Tom Scott's video on Numberphile, about time zones: https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY Maybe it's the way Tom presents it, but I do get the distinct impression that (fully) dealing with time zones is an even more maddening incomprehensible quagmire of a task than rendering text as laid out in this article.