[Fontconfig] ClearType-like results (Was:Xft - (incorrect ?) subpixel filtering. )

[Yaroslav Rastrigin]

Hello .

Well. First, Keith, I want to thank you for your reply to my message - it was 
very encouraging and motivated me enough to continue investigation (I'm still 
convinced WinXP ClearType provides much more readable text output on 
not-so-highres LCDs than any other technology). Your comments were also very 
valuable.
What I have now : 'reference' (as seen on http://grc.com/cleartype.htm) 
implementation of 5-level filter. Results are quite promising, although still 
not on-par with CT (text is a bit more blurry/slightly bolder (sp?) than CT's 
output).  (I could provide results, if somebody is interested).
I tend to think this is because either 
a) MS core TTF fonts supplied with XP probably have some more additional info 
with proper weighting coefficients (ClearType hints ?). Could someone 
confirm/deny it ?
b) Incorrect/too simple formulae to calculate each subpixel's value 
distribution. Is there any patent/techdoc info about MS ClearType's used 
algorithms ? Would it be called 'patent infringement' if such a patent exists 
and similar technique will be implemented in Xft  ? 

And one more question, this one must probably go to freetype-devel ml, but in 
case somebody knows - is there any way to use freetype2's grayscale renderer 
in monochrome mode - without gray smoothing ? Since AA wll be done on 
filtering stage, additional grayscale blurring is not only unnecessary, but 
greatly adds to 'boldness' of visible results. I've looked through 
src/smooth/ftgrays.c and compressed 'coverage' range from 0..255 to two 
levels - 0 and 255       
(gray_hline(), ftgrays.c:~1394
     if (coverage < 96)     // Empirically chosen value                                                             
      {                                                                                   
        coverage = 0;                                                                     
      }                                                                                   
      else                                                                                
      {                                                                                   
        coverage = 255;                                                                   
      };
)

This step greatly improves sharpness and readability, while maintaining nice 
antialiasing, but (of course) introduces (or, rather, emphasizes) rendering 
artifacts. (Tahoma 10 pt 'k' lower diagonal stem missing few pixels, f.e.).
I've tried to understand used algorithm, and it seems it's almost impossible 
to have non-antialiased output with this renderer. So, the question is - am I 
wrong or do I need to write new renderer ? The task is simple - just render 
glyphs with 3x horisontal resolution, without any attempts to smooth 
resulting bitmap. Or, maybe, some other already existing renderer would 
suffice ?

-- 
With all the best, yarick at relex dot ru.