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