>>> 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
_______________________________________________ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
