[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft] Seeking answers on subpixel rendering
Re: [ft] Seeking answers on subpixel rendering
Mon, 26 Mar 2007 17:14:03 +0200
On Thu, 22 Mar 2007 21:31:53 -0700 (PDT), "chojin" <address@hidden> said:
> I am a long time windows user who has, around once a year for the past 6
> or so years, tried to make an effort to switch my business (graphic design
> and web development) over to linux and the one thing consistently holding me
> back is font rendering... freetype is the best attempt so far, but is SO
> far away from windows and osx.
> I have done my best to educate myself on freetype and so on, and one of
> the few things I'm left speechless about is subpixel fonts. (Yes I am using
> an LCD, yes the bars are RGB, yes subpix is calibrated correctly for it -
> this is in regards to subpixel rendering as a method itself and not my
> specific implementation).
> Basically, it does nothing. It's a massive scam. It just produces slight
> annoying color ringing around fonts and hinders readibility. As a test,
> here is a cooltype rendered font, then the same paragraph below it in
> As you can see, the grayscale is far more comfortable to read, with no
> annoying ringing. Yet, when subpixel rendering is turned off in freetype,
> the actual RENDERING changes. Why is this? Shouldn't subpixel just
> convert some of the antialiasing into fringe colors, corresponding to the
> adjacent rgb bars?
> What I am saying is, shouldn't type libs focus on antialiasing and
> kerning (which in themselves have a long, long, long way to go before they hit
> the same level that win/osx have) and drop the (possibly patent infringing)
> subpixel stuff? Does the bytecode interpreter have anything to do with
> this kind of antialiasing? Could an autohinter produce the quality of
> antialiasing shown above?
> Maybe I am confused but that's why I posted here - the best place to get
> an answer would be from freetype users themselves.
Well, well, I don't know exactly where to start, so I'll start randomly.
The short version is that this is an on-going battle, and that FreeType probably
isn't to be blamed for most of the issues you're facing, and that a solution
is probable though I wouldn't bet to see it deployed soon.
* First, on the topic of LCD filtering itself: its effect depends on a lot of
things, like the fabric of your LCD screen, your overall display gamma,
the text color/background being used, the eye-screen distance (really) and
your own perceptual sensitivity to the color "fringes" themselves.
I've tried to see the example image you posted with two different monitors.
On my pretty old 13" laptop, the LCD text is clearer than the gray one that
appears more blurry. However, on my work 24" Dell, the difference is a lot
less significant. In no way is the "gray" text "far more conformtable" to
read to me.
Similarly, I have a 15" MacBook Pro for work. Its display is very bright and
colourful, but it displays LCD text with very visible color fringes to my
eye (and the "gray" text is blurry anyway). However, when I hook up the same
computer to my 24" Dell, everything looks really good.
I have tried to play with display settings to change that, but can't reproduce
the same quality on the Mac's screen in any way. Some other people don't seem
to see any colors on the Mac.
So I don't agree it's massive scam, it just depends on lots of factors.
* Second, you are true that LCD filtering and hinting are two separate issues.
The fact that you select "LCD rendering" in Linux and see some changes in text
rendering come from libraries like libXft, Cairo or Qt that use FreeType
and your font settings incorrectly.
Another problem is the design of the font preferences dialog which is simply
misleading, and from a user-point of view, buggy. However, that's a different
problem I would prefer not to address here.
* regarding the very visible color fringes you're seeing in Linux, they come
the fact that the default LCD filter being used in libXft and Cairo was
solely for the case of TrueType fonts with very high-quality bytecoded hints.
this means that you need to enable the bytecode intepreter to get anything
sensible out of it. If you don't, you'll see these atrocious blue/yellow
all over the place. Even if you do, you'll see them on a lot of fonts that
have high-quality hints anyway.
I've provided patches to these libraries to get rid of this problem a long
ago. For some reason, these have not been integrated in the respective
See http://david.freetype.org/lcd/ for details.
A better filter works consistently across all fonts and hinting modes, though
can produce slightly more blurry glyphs in the high-quality case. recent
of FreeType provide such a filter, but it is not used by Cairo and LibXft yet.
* As an example, here are four snapshots of my current desktop. They represent
same content rendered through four different hinting/rendering combinations
should give you an idea of what is possible with FreeType:
note that some pretty important label displacements between versions, these
from what appears a bug in Firefox which is somewhat confused when asked to
a page after you alter your font settings (it does that all the time, even on
* My personal favorite is to use the "light" hinting mode, with or without LCD
depending on the screen I'm using (definitely on my home laptop, not on the
The rendering is very close to what you'll get with Mac OS X, with the
you won't see sub-pixel positioning.
Most people won't see a difference anyway. And though it's possible to do
FreeType (the auto-hinter even supports sub-pixel positioned hinting, though
is not usable from the API at the moment), it's the rest of the graphics
stack on Linux
that is not ready to use it.
* I still force myself to use the "normal" hinting mode, since I like to eat my
food to be able to improve it as much as possible.
* Regarding matching ClearType rendering, this is more subtle than it seems
- ClearType in Vista is different from ClearType on XP; at a minimum, the LCD
can be different, and it seems Vista supports sub-pixel positioning now
LCD and "gray" modes)
- supporting ClearType-like rendering is possible using FreeType, but must be
done on top of it. Basically you need to produce bytecode-hinted text at 3x
resolution (which is different that dilating 3x horizontally glyph outlines
loaded at 1x
the resolution), then apply the LCD filter. There are also a few
whose behaviour changes, but nothing too drastic.
there are however some issues regarding the sub-pixel advances and how they
used to perform text layout.
- more importantly, Microsoft has several patents covering the ClearType
(which do not amount to a lot of things, by the way). Some of the claims in
patents are very broad and likely have prior art. For example, I've seen
text rendering on delta-nabla LCD screens a *long* time before ClearType was
however, certain claims might not be easily invalidated, and it's unknown
at the time
wether it's possible to implement something that doesn't infringe on them.
prior art, if it exists, need to be clearly identified.
- since FreeType is used in many embedded devices, I don't want to enable a
could cost unsuspecting developers millions in a few years when Microsoft
"payback" time. That's why the LCD filtering in FreeType is disabled in all
builds and you need to enable it manually (just like the bytecode
It seems that libXft and Cairo authors, which perform their own LCD
filtering in their
respective code, don't feel it's important. that's their point of view, and
Also, because of the patents issue, I'm not going to lose my time on this
If someone wants to implement it in Cairo/LibXft/Qt/Whatever, please do it;
Voilà, I don't know if this answers all your questions, but it's already plenty
to digest. I advise you to lobby the Cairo/LibXft authors if you want better
- David Turner
- The FreeType Project (www.freetype.org)