>> That "pale/'washed out'" may depend with on the gamma >> adjustment you apply to the generated pixmaps when rendering >> them on the target.
> Has the value for the gamma adjustment been changed in FreeType after > version 2.6.1? AFAIK Freetype does not do gamma adjustment, you do it when writing the application code. Many applications don't do it, so anti-aliased glyphs look usually fuzzier on light backgrounds than on dark backgrounds, and since it seems most developers have dark backgrounds they don't feel a need for adjusting gamma. https://freetype.org/freetype2/docs/tutorial/step1.html “Once you have a bitmapped glyph image, you can access it directly through glyph->bitmap (a simple descriptor for bitmaps or pixmaps), and position it through glyph->bitmap_left and glyph->bitmap_top. For optimal rendering on a screen the bitmap should be used as an alpha channel in linear blending with gamma correction.” https://lwn.net/Articles/669024/ “On low-DPI screens most of us are sadly stuck with, the situation is different. The pixels are too large for most of the details of a glyph and shades of gray are the norm rather than the exception. This is relevant because all our screens have a second problem: they are not linear. 1 + 1 is not 2. Twice the value does not result in twice the brightness. When a pixel is only 50% covered, the coverage map says 50% black, and this translates to a pixel value of 128 when you use 8 bits per channel (0-255). However, this does not translate to 50% brightness for that pixel on our sRGB and gamma 2.2 screens. Due to their non-linearity, they dwell longer in the darks and only a pixel value of about 186 results in 50% brightness – 128 ends up too dark on both bright and dark backgrounds. The net result is that dark text looks burnt-out, pixely and blotchy on bright background, bright text too frail on dark backgrounds, and colored text on colored background (for example, red on green) seems to have dark halos or ‘dirt’ around it. The situation is especially ugly for diagonal stems like in glyph ‘w’, where the quality of FreeType's anti-aliasing depends on the correct display of grays. On high-DPI screens where smaller, fully black pixels reign supreme, this doesn't matter, but on our low-DPI screens with all the gray shades, it does. 0% and 100% brightness are the same things in linear and non-linear space, just all the shades in-between are not. The correct way of rendering a glyph image on a surface is to alpha blend it onto the surface in linear space and then apply gamma correction to translate the linear coverage map to something that is correct for our screens. No toolkit in the Linux ecosystem does it by default, even though Qt5 and Skia can and will do it on other platforms. Windows and Mac OS X do it natively. This procedure is especially important if glyphs should be subpixel-rendered (ClearType and Mac OS X) with as few color fringes as possible.”