Re: [ft] Seeking answers on subpixel rendering

[David Turner]

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)