Re: [ft] anti-aliasing question

[Werner LEMBERG]

>>> Is there an LCD mode which does not grow the image size?
>>>
>> No.  You need three colour channels for LCD rendering.
>
> What is the format of the bitmap memory when FT_PIXEL_MODE_LCD is in
> place?  The docs say 8-bit, but it being 3x as wide suggests maybe 1
> byte for each color component?

Yes.  I thought this is obvious, however, it doesn't seem so.  Any
improvements to the documentation are welcomed.

>>> I see FT_RENDER_MODE_LCD and LCD_V which both indicate that they
>>> produce larger-than-normal bitmaps.  I tried FT_RENDER_MODE_LCD
>>> and of course the text glyphs were all 3 times as wide (as the
>>> docs indicate).  Am I supposed to then shrink them back down?
>>
>> No, you are supposed to apply a colour filter.
>
> What would the pseudo code be for that?

You have to do the RGB colour manipulations directly on the image
buffer.

> I tried calling FT_Library_SetLcdFilter, but the resultant image is
> still 3x as wide.

Of course.  With `colour filter' I don't mean that you are reducing
the colours back to the original size – in this case it would be
completely useless to call an LCD rendering mode at all.  Instead, the
filter should distribute the colour values differently, depending on
the values of a pixel's neighbors.  To be more precise, you have to
convert the B/W rendering of a glyph with a horizontal resolution
increased by factor 3 into RGB values suitable for LCD rendering.

> Is there some other call I need to make to enable the color filter?

You have to define FT_CONFIG_OPTION_SUBPIXEL_RENDERING so that you can
select one of the three available colour filters with
FT_Library_SetLcdFilter.  There is no callback hook to add a new,
external colour filter function.

To get acquainted with subpixel rendering, please read

  http://www.grc.com/cleartype.htm

which gives an excellent introduction to the topic.


    Werner