Re: [Devel] ClearType-like results

[David Turner]

Yaroslav Rastrigin wrote:
> Hi !
>
> My question is simple - what should I do to achieve ClearType-like results in 
> subpixel-antialiased text rendering ? Is there any way do do aforementioned 
> rendering "MS style ?".
>
There are several ways to achieve LCD-optimized rendering. I'm not even certain
that the ClearType in Windows XP is the same than the one found in the original
"Microsoft Reader" program that I downloaded some time ago. Adobe Acrobat 5
also implements it differently than Windows, so do libXft (which does manage
sub-pixel decimation !) or FreeType itself.

> After comparision of freetype and cleartype outputs,
> main difference is: cleartype engine never "blends" main character shape, and 
> only adds brown/blue dots _around_ it.
>
This is not true, even if you can get this impression if you only study black
text on a white background. MS's ClearType works with colored text so it does
"blending", at least in Windows XP (and libXft). I believe that this is not the
case with Microsoft Reader and Adobe Acrobat.

> freetype's method, OTOH, (or, at least, as I'm understanding it ) modifies 
even
> pixels that would be  black in non-anti-aliased mode. Resulting freetype 
output looks
> "lighter", less brightness- and color-consistent and leads to ugly bugs 
> including missing "Z" diagonal in Times New Roman Italic, substantially 
> lighter right part of "k" in Tahoma and some other not-so-pleasant effects.

These "effects" are also visible with standard anti-aliased rendering with these
fonts and directly come from bad native TrueType hints in the fonts. This has 
nothing
to do with "sub-pixel rendering". When ClearType is not active, Windows always 
displays
these fonts in monochrome at small character pixel sizes.

> I've browsed through ftgrays.c (as I could understand, this is the 
> antialiasing engine of freetype) but haven't found any compile- or runtime 
> defines/settings to tune smoother's behavior.
there is nothing in ftgrays about sub-pixel decimation, since it only deals
with converting outline into gray-level bitmaps at the pixel or sub-pixel
level.

Now, here's a small "generic" description of how to produce sub-pixel optimized
text:

  1 - adjust outline hinting for the sub-pixel space.

  2 - dilate the resulting outline by a factor or 3 in either the horizontal
      or vertical direction.

  3 - render the resulting outline into an 8-bit pixmap. However, the pixel
      buffer should be read as a RGB buffer (in the horizontal direction)

  4 - *filter* the resulting RGB pixmap to reduce color bleeding

  5 - "blend" the resulting glyph to the target pixmap. This requires
      a special blitting operation where each R,G,B channel has its own alpha
      value taken from the filtered pixmap. This may also require gamma
      correction !!


FreeType 2 allows you to perform steps 1, 2 and 3 rather easily. The filtering
and blending parts are not. Because the glyphs are not filtered, you'll 
experience
unpleasant color frings in the output of "ftview". For now, this is normal, 
though
we may want to add filtering to the "ftview" program, or add a new API like
FT_Set_RGB_Filter(..) to make it part of the engine some day.

For you record, libXft implements 1+2 with the following scheme:

  A - load normal glyph outline:  FT_Load_Glyph( face, gindex, 
FT_LOAD_NO_BITMAP )
  B - dilate it three-fold in the horizontal or vertical direction  
(FT_Outline_Transform(..))
  C - render it to an 8-bit bitmap with FT_Render_Glyph()

New load flags were introduced in the FT2 API recently to let you
perform the following automatically:

  A' - load and hint glyph outline, optimize automatic and Postscript
       hinting for RGB sub-pixels

  B' - render an outline into a RGB pixmap directly (the outline dilation
       is performed by FT_Render_Glyph transparently)

the flags are FT_LOAD_TARGET_LCD and FT_LOAD_TARGET_V, they're used to
"group" FT_RENDER_MODE_LCD+FT_PIXEL_MODE_LCD and 
FT_RENDER_MODE_LCD_V+FT_PIXEL_MODE_LCD_V
respectively.

the result of A' is different from the one in A. Note also that for now, A' 
doesn't
change the hinting of TrueType fonts when using the bytecode interpreter.

The result of A is different from MS's ClearType, some people like it better, 
some
don't.

In all cases, there is no point of producing sub-pixel optimized glyphs if you 
don't
have the necessary filtering and blending routines as well (fortunately for 
Linux users,
these are provided by libXft and the RENDER extension respectively).

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)


--
This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error, please
delete it and immediately notify the sender.
Any use not in accordance with its purpose, any dissemination or disclosure,
either whole or partial, is prohibited except formal approval.
The E-Mail transmission can not guarantee the integrity of this message.
CANAL+TECHNOLOGIES will not therefore be liable for the message if modified.