
State of Text Rendering (2010) - lelf
http://behdad.org/text/
======
Tiksi
Slightly related, for arch linux users (and probably others but I can't say
for sure) the infinality fonts bundle can GREATLY improve font rendering, and
is also highly configurable to taste:
[https://wiki.archlinux.org/index.php/Infinality-
bundle+fonts](https://wiki.archlinux.org/index.php/Infinality-bundle+fonts)

------
streptomycin
_What we need is the GNOME3 of text rendering_

That is scary to imagine :)

~~~
captainmuon
Indeed it is. A lot of wonderful work has went into FreeType and Pango. Linux
font rendering went from the worst to (arguably, and when well-configured) one
of the best.

I do hope that they don't go a few steps back in a case of "rewrite
everything". Example of who did: Metro apps in Windows 8 no longer use
ClearType (RGB subpixel rendering), but plain greyscale antialiasing. I
believe many Desktop apps are falling back to it, too. It looks like pre-
windows XP. It's easy to miss the correct flags as a developer, and many
people don't care enough or don't have the eyes to see the difference, but
it's annoying for those who do care.

Lets just hope that they get everything right with fonts with the switch from
X to Wayland...

~~~
kllrnohj
> Example of who did: Metro apps in Windows 8 no longer use ClearType (RGB
> subpixel rendering), but plain greyscale antialiasing.

That's a victim of mobile-optimized toolkits. RGB subpixel rendering doesn't
work on GPU-accelerated UIs that are on devices that are rotated. As in, it's
expected to have the subpixel ordering change semi-frequently, and that change
needs to happen as fast as possible. Since all the text is cached in GPU
textures, that would require tearing down the font caches and re-building them
every time the user rotates. That's prohibitively expensive, which means no
RGB-subpixel rendering.

On mobile devices this hasn't been an issue because raw density saves the day.
Your average phone's pixels are smaller than your typical desktop/laptop's
subpixels. Maybe some day desktop/laptop will get a density boost, maybe...

~~~
anon4
Or, you could render to greyscale texture at 3x resolution and then scale down
the texture with subpixel precision when rendering on screen?

~~~
jahewson
Subpixel smoothing requires vector outlines to get good results, so scaling a
bitmap won't work in practice. More importantly, font rendering is optimised
to a specific size, i.e. the bitmap for 32x32 isn't just a scaled version of
the 16x16 bitmap. The usual mechanism for this is hinting, but some engines
use their own heuristics (e.g. CoreText, and maybe Metro?).

------
UIZealot
> CJK users want the Latin to be rendered using the same font used for CJK.

Not true. Latin characters in CJK fonts are ugly beyond belief. I think most
CJK users either just don't know what they're missing, or don't care enough to
make a lot of noise.

If you're leading a text rendering project, please, for the love of humanity,
allow CJK users to use a Latin font for Latin characters!

------
616c
As one of the few terminal users of Arabic in this site (emphasis on the
terminal part), I want to thank Behdad and others for harfbuzz and other great
libraries. His contributions have been significant, and BiCon Arabeyes project
was one of the first and only ways to show Arabic in the terminal. This was
even before SIGWINCH was a signal you could use IIRC, so that I cannot even
run it in tmux, screen, and other dynamically-sized terminal emulators without
a massive, massive headache. But before that, there was not much of anything.
And things have come a LONG, LONG way since then, even if there is plenty more
road ahead.

I started using Linux almost ten years ago, and the winter for RTL languages
were just starting to thaw.

Since I have come to using Arabic more often in the terminal, you would be
suprised how often this causes problems as text rendering is done at many
different layers and there is no harmony between them. Not only does it mean a
special terminal emulator (mlterm for the win; esoteric but the only one that
handles Arabic properly and handles Chinese, many Indic languages, and Hebrew
unlike anyone else) but has all minaskinds of edge cases. Text rendering
happens at so many layers and with different libraries, you have to make
runtime changes to get certain programs to behave with each other. As a heavy
Emacs user, Emacs will conflict with its own (default on) bidi implementation
using m17n-lib (as mentioned in the article). So what happens? Arabic and
other RTL languages go back to the original order, English-style, which is not
what you want, as the operation happens twice since mlterm also uses this
library (m17n-lib), but is not aware the bidi reordering happened before at
the application layer. I finally got so sick of this my most important Emacs
keyboard macro is to toggle off the Emacs internal bidi ordering on and off.
Why you ask? Because despite mlterm and Emacs using m17n-lib on my computer, I
need GUI emacs to use its own internal Bidi scheme, and the terminal run Emacs
(emacsclient -nw) to run without out, and let mlterm pick up from there. I
have tried other terminal emulators (someone wrote Perl scripts using, IIRC
Text::FriBidi based one of the aforementioned library, GNU FriBidi) for urxvt
to handle this), but it does not work as well: you get the correct ordering,
but Arabic letters do not connect (this is really glyphs, not letters, but I
digress). So if I do not toggle the Emacs macro I made, I cannot have a
terminal that will show Arabic file names properly at the same time outside of
Emacs, and a simple `ls` is all borked up.

GUI programs are not so much better. I run i3 with my own customizations,
including heavy use of the wonderful dmenu utility for searching files indexed
with Recoll, connection to my password manager, and running programs on the
fly. Probably is dmenu specifically does not support Unicode at all, let alone
RTL languages like Arabic, so you get a mess. I love suckless tools; and they
avoided Unicode for a reaosn, but suckless, a very common group of power user
tools ignoring Unicode for their own good and embracing their mantra of well
manicured C code tells you to pity developers who do take the time and bear
lots of whining about this crap being inconsistent and having crazy edge
cases.

These edge cases will not stop me from using free software, because I had no
idea how complicated Arabic rendering was until using Linux, and a lot of this
crap flat out is not possible in Windows anyway (try listing Arabic file names
in Command Prompt), and is still terrible when you get around to it working.
Do we need a "GNOME3 of text rendering" as others quoted in the threads here?
I am not sure we do. What we need is standardization of libraries or
generalizing backends to choose what you need, a la Freedesktop initiatives in
other spheres. Ironically: every terminal emulator and app
developer/maintainer retorts when present RTL Arabic problems: this is an
application layer concern and out of my hands. And what they ignore app
developers with their application layer concerns apply with different layers
of libraries unevenly, hence the aforementioned hacks. To resolve this means
removing a lot of what makes Open Source with forced standardization, and
contributions like that of Behdad wonderful: choice. So I prefer to stick with
more choice, or promoting/encouraging different text rendering applications to
support different backends and more importantly properly detect the existence
of each other when used. I am not a C programmer, but I think that is already
where we are in the FOSS world. It is more a matter of awareness and interest:
like other software markets (commerical or not), FOSS software with any
significant user base will catch up. Find me Bengali Windows and I will laugh
at you, but I have seen real impressive work with regionalized Linux distros,
with full documentation for Indian communities that nothing proprietary comes
close to because there is no interest.

Behdad, thanks again for your work. This is the second time your stuff up on
HN in recent memory. I remember emailing you about BiCon years ago and you are
still one of my open source heros with HarfBuzz and FriBidi and all that
stuff. Keep up the good work and thank you for making FOSS software
international.

~~~
behdad
Hi,

Thanks for the nice words. I wrote BiCon over ten years ago and never touched
it again. It definitely wasn't before SIGWINCH was introduced as I was barely
four years old then :).

I checked the code, looks like code for SIGWINCH was there, but not working. I
believe this got broken during the pty rewrite we did back then. At any rate.
I just fixed that, and fixed initial window size. Enjoy, and in the future,
feel free to shoot me an email if something I maintain bothers you!

    
    
      https://github.com/behdad/bicon/commits/master
    

Cheers, behdad

~~~
616c
Ah. Well then correction, you told me SIGWINCH was not implemented in BICON
and you did not have the time to work on it, which is definitely understable.

------
bryanlarsen
This was originally from 2009, although it received a minor update in 2012.
According to the author:

Overdue for an update, still a good read to understand the pieces of the Free
Software text rendering stack.

------
ktzar
An article like this deserves an image.

