Re: [ft] changing the depth of gray for anti-aliasing

[Peter Grandi]

[ ... ]

>> [ ... ] However, you might experiment with changing the gamma
>> value (this is the job of your GUI). [ ... ]

> Ahhh interesting indeed. It turns out that gamma has indeed a
> profound effect.

Having seen that gamma matters I have used that as a keyword in
the archives for this mailing list and found for example these
two:

http://lists.nongnu.org/archive/html/freetype/2010-02/msg00055.html
 "An important thing is to apply gamma correction, if necessary.
  In particular, black on white needs a different gamma compared
  to white on black."

http://lists.nongnu.org/archive/html/freetype/2010-02/msg00037.html
 "As others have mentioned, you can also tweak the grayscale
  values by applying a gamma function on the bitmap. I've found
  a gamma value of 0.7 and 1.4 to be good for text rendering,
  depending on whether you're rendering black on white or white
  on black."

and it seems that it is the *application* that is supposed to
apply gamma correction, because only the application knows the
colors on which the pixmap created by Freetype2 will be applied.
Relying on monitor/X server gamma would I guess satisfy this.
There is some more discussion here:

  http://www.infinality.net/forum/viewtopic.php?f=2&t=104&start=20

In my case that means Qt3 or Qt4 (KDE3 and KDESC4) and Gtk2 (for
Emacs 23 etc.). I found reference to an "infinality" patch that
builds this into Freetype2, but then I found this very sad analysis:

http://antigrain.com/research/font_rasterization/
 "When using anti-aliasing, the color compositing must be done
  in the linear space, but before displaying you have to convert
  the resulting image to sRGB."

 "The situation is even worse. You can apply gamma=2 to the
  Linux screenshot in Irfanview (Image/Enhance colors…) and look
  at the text. Please try to ignore the fact that the pictograms
  look too "whitish", concentrate only on the text. [ ... ]
  Do you like it? I still don't. When I was working on text
  rendering in AGG, I though that proper gamma correction should
  solve all the problems. Nothing of the kind! No matter how
  well it works, some elements look thicker, some others thinner
  than the vertical and horizontal ones. It's especially visible
  with the sans-serif group of fonts, and especially, when the
  strokes are strongly aligned to pixels.

  The problem is TrueType hinting for small glyphs was designed
  specifically for a regular, aliased B&W rasterizer! The use of
  anti-aliasing of any kind is inappropriate, while most Linux
  people do namely that."

and more with some positive comments on the Freetype autohinter.
Which I enable in any case with anti-aliased text, because of
the Freetype FAQ that says it usually gives better results than
font-specific hinting.

I don't like very much the conclusion though:

 "So, in short words, for the nice looking text with accurate
  horizontal positioning we need the following.

  1. Use horizontal RGB sub-pixel anti-aliasing for LCD flat panels.
  2. Use vertical hinting only and completely discard the horizontal one.
  3. Use accurate glyph advance values, calculated at a high resolution for 
unhinted glyphs.
  4. Use accurate, high resolution values from the kerning table.

  Slight gamma correction may improve the result, but it's not
  mandatory. The text looks good enough even in direct sRGB,
  which means there are no potential problems when using inverse
  color schemes.

  You can easily achieve a nice result with FreeType and its
  auto-hinter. It means that you don't have to worry about
  licensing the native TrueType hinting."

I don't like subpixel rendering because of the fringing. However
the new LCD filters in Freetype2 are pretty good though.

But after a few tests it looks to me that subpixels rendering
with 'lcddefault' or 'lcdlight' filters don't show color
artifacts mostly because the result is almost identical to
gray-only anti-aliasing (and if the autohinter is enabled they
seem identical). BTW I prefer using 'xterm -fa ....'  with
attributes to 'ftview', as for example in:

  xterm -fa 
'courier:scalable=1:size=10:hinting=1:autohint=0:hintstyle=medium:antialias=1:rgba=rgb:lcdfilter=lcdlight'

(I use 'scalable=1' because I have both the PCF and Type 1
fonts).