Re: [ft] Modifying/Enhancing the Truetype Interpreter

[Moony]

> While hinting, the four extra phantom points which control the
> horizontal and vertical advance width aren't handled specially.
> However, they are stored separately (`pp1' to `pp4' in the `TT_Loader'
> structure).  In ttgload.c, the `TT_LOADER_SET_PP' macro sets them; and
> in `compute_glyph_metrics' they are used to set the advance width.
>    

Ah yes... commenting out the setting of the advance width gets past this 
issue.  Included in latest patch.

> Perhaps something along the following:
>
>    . Add a no-op FDEF the the FDEF table.
>
>    . In `Ins_FDEF', replace the call to `SKIP_Code' with a new function
>      which additionally checks for interesting patterns.  If we have a
>      match, point to the no-op FDEF instead of the current one.
>    

I temporarily added some hacky code into the FDEF[] function to detect 
opcode patterns.  One in particular that handles "VacuFormRounds" gets 
past a lot of artifact issues with legacy MS and apple fonts.  It makes 
a lot of them usable anyway.  I'm using this current patch of freetype 
on my system right now, and I'm very happy with most of the legacy font 
rendering in LCD mode.

I think the vertical stem-snapping is going to be the most difficult of 
the issues to get past, due to the fact that the whole idea with the 
freedom vector (x) is that you want to NOT force it into a position.  
Following the TT hints exactly results in a glyph that is too hammered 
into a certain spot, but ignoring it completely results in fuzzy 
letters.  Finding a good medium would be nice, but I'm struggling to 
figure out how to do that.

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?  Also, I'm still having a hard time 
understanding the whole 1/16 pixel in the x direction.  Perhaps doing 
this helps with the stem-snapping?


This latest patch has the following changes:

- It is a *GIANT slop-fest* that is in no way intended to be proper or 
efficient!  I'm just trying to get it done conceptually, and then worry 
about efficiency, etc.
- VacuFormRound function is detected and disabled, fixing a lot of 
artifacts in legacy MS fonts.
- DeltaP is now disabled after iup[x] and iup[y] are called (using some 
global variables ;D ), because it seems like deltaps after those 
generally results in dents in the outline.  The correct way is 
supposedly to skip everything but touched points in the non-freedom 
direction, but I am still trying to figure out how to do that.  The 
iup[x] and iup[y] are a rough approximation of the correct way...
- In general, bolds and italics look very nice, because they tend to not 
align with stems (or are thick enough to not notice).  In most respects, 
and on most fonts, I am happier with how this renders them as opposed to 
the existing freetype TT interpreter.  PPEMs where the vertical stem 
width is close to 1 pixel still need some work, IMO.
- On my system at least, I find that changing the light FIR filter to { 
32, 48, 102, 48, 32 } makes color fringes much less apparent.  YMMV.
- Arial and Times have some issues with the width getting out of control 
when I set the project_x to return "1" at all times.  If I return "dx" 
(the default), it breaks some glyphs on bold fonts (like 0, o, and other 
things with parallel vertical stems like h, n, m.).  I'm trying to find 
the condition to separate these two things but have been unsuccessful so 
far.


http://www.infinality.net/files/ttinterp.20100323-1.patch