[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft] Seeking answers on subpixel rendering
From: |
David Turner |
Subject: |
Re: [ft] Seeking answers on subpixel rendering |
Date: |
Mon, 26 Mar 2007 17:14:03 +0200 |
Hello Chojin,
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
> grayscale:
>
> http://www.nabble.com/file/7364/whysubpixelsucks.png
>
> 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
from
the fact that the default LCD filter being used in libXft and Cairo was
designed
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
fringes
all over the place. Even if you do, you'll see them on a lot of fonts that
don't
have high-quality hints anyway.
I've provided patches to these libraries to get rid of this problem a long
time
ago. For some reason, these have not been integrated in the respective
libraries.
See http://david.freetype.org/lcd/ for details.
A better filter works consistently across all fonts and hinting modes, though
it
can produce slightly more blurry glyphs in the high-quality case. recent
versions
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
the
same content rendered through four different hinting/rendering combinations
and
should give you an idea of what is possible with FreeType:
http://david.freetype.org/freetype/example-normal-gray.png
http://david.freetype.org/freetype/example-normal-lcd.png
http://david.freetype.org/freetype/example-light-gray.png
http://david.freetype.org/freetype/example-light-lcd.png
note that some pretty important label displacements between versions, these
come
from what appears a bug in Firefox which is somewhat confused when asked to
reload
a page after you alter your font settings (it does that all the time, even on
the
simplest pages).
* My personal favorite is to use the "light" hinting mode, with or without LCD
filtering
depending on the screen I'm using (definitely on my home laptop, not on the
24" Dell).
The rendering is very close to what you'll get with Mac OS X, with the
exception that
you won't see sub-pixel positioning.
Most people won't see a difference anyway. And though it's possible to do
that with
FreeType (the auto-hinter even supports sub-pixel positioned hinting, though
this
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
own dog
food to be able to improve it as much as possible.
* Regarding matching ClearType rendering, this is more subtle than it seems
because:
- ClearType in Vista is different from ClearType on XP; at a minimum, the LCD
filter
can be different, and it seems Vista supports sub-pixel positioning now
(both in
LCD and "gray" modes)
- supporting ClearType-like rendering is possible using FreeType, but must be
essentially
done on top of it. Basically you need to produce bytecode-hinted text at 3x
the horizontal
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
interpreter bytecodes
whose behaviour changes, but nothing too drastic.
there are however some issues regarding the sub-pixel advances and how they
can be
used to perform text layout.
- more importantly, Microsoft has several patents covering the ClearType
"technology"
(which do not amount to a lot of things, by the way). Some of the claims in
these
patents are very broad and likely have prior art. For example, I've seen
sub-pixel
text rendering on delta-nabla LCD screens a *long* time before ClearType was
released.
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.
Also, the
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
feature that
could cost unsuspecting developers millions in a few years when Microsoft
feels it's
"payback" time. That's why the LCD filtering in FreeType is disabled in all
default
builds and you need to enable it manually (just like the bytecode
interpreter).
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
I don't
share it.
Also, because of the patents issue, I'm not going to lose my time on this
"feature".
If someone wants to implement it in Cairo/LibXft/Qt/Whatever, please do it;
I don't
really care...
Voilà, I don't know if this answers all your questions, but it's already plenty
of info
to digest. I advise you to lobby the Cairo/LibXft authors if you want better
rendering
results...
- David Turner
- The FreeType Project (www.freetype.org)