Re: [ft] Modifying/Enhancing the Truetype Interpreter

[Moony]

Hi Werner,

> > Another thing I'm struggling with is how to detect whether points
> > have been touched in the non-freedom vector direction during
> > deltaps.  Do you have any insights into this, Werner?
> >      
> Can you elaborate?  What do you want to achieve?
>    

I think I've gotten past this problem by looking at other parts of the 
code.  Essentially, I wanted to detect (based on the desription here:  
http://www.microsoft.com/typography/cleartype/truetypecleartype.aspx ) 
whether points had been touched in the Y direction.  I figured out how 
to do this with:   FT_CURVE_TAG_TOUCH_Y & CUR.pts.tags[point] == 0.


>    
> > Also, I'm still having a hard time understanding the whole 1/16
> > pixel in the x direction.
> >      
> What's do you mean with a `whole 1/16 pixel'?
>    

Sorry, I'm using English colloquialisms.  :)  You can remove the "whole" 
part from my sentence.  What I was struggling with was why it was 
necessary to split the grid into 16 pieces in the x direction, as 
opposed to simply /not rounding at all/.  I'm still not sure why this is 
necessary, other than the possibility that this made sense to MS in how 
they implemented their TT interpreter code.  The freetype code can just 
*ignore* this grid completely, as far as I can tell.  Regardless, I put 
into my temporary patch a variable called "grid_factor", which lets you 
define what to use in the X direction-  1px, 1/2px, 1/16px, 1/32px, 
etc.  I've gotten the best results with 1/32 of a pixel, which is really 
as far as the freetype code can go.


I have been working furiously on getting this patch working well with a 
variety of fonts.  I have the patch to a point where it renders most 
legacy and CT fonts *very well* with subpixel hinting.  All bolds and 
italics look great, and most roman fonts.  There is still something that 
the MS interpreter does (that isn't documented in the whitepaper) to 
snap some stems to the grid.  I can't figure out how to do that without 
ruining the glyphs though.  (My guess is that they put lots of hard-code 
in place.)  I have redesigned the patch so that it now doesn't ingore 
the x direction in the "move" functions but rather in the "round" 
functions, as stated in the whitepaper.  This *does* produce better 
results I've found, but it required more conditionals on MIRPs and 
stuff.  I can tell that MS must have hard-coded a bunch of things in 
their interpreter, like, "if font=verdana, always do DELTAP"... or "If 
function 72 is an inline delta, ignore it", etc.  If I implement the 
patch as stated in the whitepaper, it breaks fonts.

I am in the process now of cleaning up the patch, but I will post it 
soon.  I am completely open to criticism of it, and suggestions of 
improvement.  There may be parts of it that are inefficient and not up 
to C coding standards, and I would welcome any suggestions on how to 
make it work the way you would like.  My idea is to use #ifdefs to 
determine whether "grayscale" is enabled, and if so, to use the new 
method I've developed, otherwise, if grayscale is not enabled, do the 
old method that works well with bi-level rendering.  Does this approach 
make sense to you?  If not, what would you like to see?

Thank you!