
Text Rendering Hates You - robin_reala
https://gankra.github.io/blah/text-hates-you/
======
euske
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
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.

~~~
earthboundkid
Japanese is one of the few languages with a worse writing system than English.
Hats off to them for it. I do miss the pre-war spellings though, where they
wrote things based on 10c pronunciation, eg AU is pronounced OH (like in
French).

Tibetan is also in pretty desperate need of spelling reform. I’d love to hear
replies about other terrible writing systems.

~~~
gumby
In the scheme of writing systems it's hard for me to see why English is so
bad. In general writing (like spoken grammar) is so heavily used that all the
"rough corners" get sanded smooth pretty rapidly and continuously. For
example, though the histogram of Kanji/Hanzi has a very steep drop-off, it's
not that hard for people to recognize and keep track of, because characters
that were hard to read at first tend to get restructured or dropped.

As far as Indo-European languages go, languages like English and French are
quite conservative in spelling and underlying meaning, which means they do
diverge from pronunciation but retain semantic clues which help the reader
unlock the meaning of unknown words. While languages that continuously reform
to try to match pronunciation shifts (e.g. German) discard this info. In
addition they have to pick one canonical pronunciation, and themselves
typically retain various homophonic issues (e.g. how many ways can you write
the sound of ä (I don't mean "ae")).

Even as a kid (should be "easy to learn", right?) I struggled far more with
the variants of the devanagari alphabet even though it was so phonetic. But
hundreds of millions of people use it every day without thinking about it.

~~~
earthboundkid
English is pretty bad unless you are a total orthography history nerd.

For example, people routinely mispronounce the name of the President of China.
(It’s closer to Shi than Zi.) Why? Because English has a strong preference for
retaining native spellings even when the other language has a completely
incompatible set of pronunciation rules. With Chinese this is extra silly
because pinyin is only one of a million ways of romanizing Chinese and
basically the least English compatible method.

English spelling is like a Hofstader puzzle: to be able to master it, you must
master the spellings of all languages plus English itself recursively going
back to the Great Vowel Shift. It’s not a good system.

~~~
gumby
Pinyin is requested by the Chinese government. They used to use Wade-Giles but
changed iirc in the 70s and requested that others do so too.

It can’t really be called part of English in any meaningful way anyway.

~~~
earthboundkid
We don't call the country "Zhongguo" in English, we call it "China". So why do
we let them tell us to call it "Beijing" instead of "Peking"? It's craziness.
We gave up a perfectly good name for "Canton" and replaced it with an
unreadable mess that isn't even in Cantonese ("Guangzhou").

If people who speak Chinese want to use pinyin, more power to them. But
English speakers need to stop just copying other people's romanizations even
when the romanizations do not connect to our spelling system at all.

------
leni536
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-
gener...](https://www.freetype.org/freetype2/docs/text-rendering-
general.html#background)

~~~
z3t4
With high density monitors on the rise we should get rid of LCD (RGB rainbows)
anti alias as its really just a hack.

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

------
dictum
> 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
Have you tried `defaults write -g CGFontRenderingFontSmoothingDisabled -bool
NO`? (also needs a reboot)

~~~
dictum
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
It does work on 10.15 latest beta (10 as of writing).

~~~
dictum
Good to know, thanks. Hope it makes it to GM.

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

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

~~~
jacobush
I miss my amber Hercules screen

~~~
reaperducer
Ashton-Tate's Framework on a green Hercules was my daily driver for a very
long time. Multi-tasking (sort of), windows, and the ability to cut-and-paste
between applications in a text-only environment years before Microsoft Windows
was usable.

[https://en.wikipedia.org/wiki/Framework_(office_suite)](https://en.wikipedia.org/wiki/Framework_\(office_suite\))

Picture:
[https://winworldpc.com/res/img/spotlight/Famework%201.0%20-%...](https://winworldpc.com/res/img/spotlight/Famework%201.0%20-%20Edit.png)

~~~
bitwize
Framework was the tits back in the day. It was basically Emacs for the office.
It built on the core concept of a frame the way Emacs built on the buffer --
except frames could contain other frames, which is how Framework composed
spreadsheets and documents with multiple subsections.

Like Emacs, Framework was programmable in a Lisp-like scripting language
called FRED. In fact you could attach FRED macros to any frame, and they would
be saved along with your work.

All this on an 8088-based PC (or 80186-based Tandy 2000).

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

~~~
bloopernova
That's the difference between ttf and otf? And that's why certain fonts look
slightly different between platforms!

This is a serious revelation to me. Thank you. I've been having to switch
between my Mac laptop, Linux workstation, Windows 10 workstation, and Windows
10 Amazon Workspace a lot. It's been frustrating seeing the small differences
but being unable to really figure out what was going on.

~~~
hsivonen
The format of outlines is only difference between .ttf and .otf, yes. .ttf has
quardratic Bézier curves and hinting is done by interpreted programs (on
Windows; TrueType has generate hints at run-time). .otf has cubic Bézier
curves and declarative hints.

The outline format of .otf comes from Adobe Type 1 fonts (.otf really is just
.ttf with outline format taken from Type 1), so the .otf outline format is the
older one. Apple created TrueType after licensing talks with Adobe failed long
ago.

.otf is generally more compact in terms of font file size than .ttf. Really
the only reason to stick with .ttf is the rasterizer situation on Windows and
outlines traveling from Linux and Mac to Windows in PDFs.

~~~
Jasper_
OpenType also supports the TrueType glyph format [0], and it's the dominant
glyph format in most OTF files I could find. Really, OpenType is just CFF /
Type 2 Fonts and TrueType smushed together in a single file.

[0] [https://docs.microsoft.com/en-
us/typography/opentype/spec/gl...](https://docs.microsoft.com/en-
us/typography/opentype/spec/glyf)

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

------
TazeTSchnitzel
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
Wow, that's an amazing (and beautifully designed) website, thank you!

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

~~~
pekim
In the first case, I believe that it's normally referred to as "subpixel
antialiasing". And in the second case, "subpixel positioning".

~~~
amelius
Yes, good point, but what would you call it if you'd apply both concepts at
the same time?

~~~
mmmrk
Subpixel antialiasing plus subpixel positioning :)

They are orthogonal concepts.

------
privethedge
> 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-cur...](https://gankra.github.io/blah/text-hates-
> you/transparent-cursive.png)

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_
Mobile Safari is giving me the color stacking in your second link.

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

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

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

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

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

------
einpoklum
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/)

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

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

~~~
lodi
To add to the confusion, OpenGL uses the term 'fragment' for what you're
calling subpixels.

~~~
dahart
Yes that’s an interesting point, the “fragment” terminology can be confusing
at first. But I think of fragments as something slightly different. “Fragment”
means basically pixel or subpixel geometry, it’s output from the rasterizer.
The fragment shader is what takes a fragment as input and then outputs the
pixel or subpixel color. Fragments aren’t necessarily involved in GPU
antialiasing, you can have subpixels in OpenGL without fragments, if you’re
doing image processing without rasterizing. In any case, it’s a good thing
that they picked a different word to define, and didn’t just call it
“subpixel”, right?

------
mmmrk
> 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-
> glyp...](https://gankra.github.io/blah/text-hates-you/#aa-breaks-glyph-
> caches)

I think the author mixes up two concepts here, hinting and subpixel
positioning.

A TrueType font can change stuff around on the x and y-axis. Applying hinting
on the x-axis messes with your layouting and prevents subpixel positioning on
the x-axis. What you do is apply hinting on the y-axis only (FreeType calls
this slight hinting, DirectWrite more or less does this -- not quite, but
close enough) so you are free to shift glyphs around on the x-axis. This helps
with displaying text with a more even texture on LoDPI screens. On *nixes,
Chrome does this, Firefox doesn't.

~~~
floatboth
+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
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.

------
likeclockwork
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
I wonder if it is partially OS-dependent? I'm also on Chrome, but see
something closest to the Safari version.

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

\- time

\- indoor positioning

------
ttsda
>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
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
The article has Safari and Edge screenshots through, so I would assume Windows
was used

------
gravitas
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
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
> 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
Completely forgot about it. Yes, it does improve readability for me.

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

~~~
chrisseaton
Where do you find bitmap fonts that are high resolution enough for modern
displays?

~~~
enriquto
No idea, sorry, I have never used a "modern" display. Yet terminus and the
standard bitmap X fonts go to quite large sizes. They are certainly readable
even when using ridiculously tiny pixels.

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

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

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

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

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

------
lostgame
I miss non-AA’d text. Like PalmOS or Windows 95.

Gotta love the sharpness of it somehow.

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

