Re: [ft] Modifying/Enhancing the Truetype Interpreter

[Werner LEMBERG]

> Some letters, for instance Arial normal "v" or "X", or bold "s"
> appear to have TT instructions that move the right bearing toward
> the left, a pixel or so (figured this out with FontForge debug).
> This results in "s" or "v" being smashed up against the following
> letter at certain point sizes.  (see screenshots).  Which part of
> the ttinterp.c code would control this moving of the right bearing,
> in order that we can disable that part?  (It appears that the MS
> engine got around this problem by keeping instructions on the glyph
> in the x-direction, to fit into this smaller space, but IMO, it
> looks bad.)

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.

> Gamma / LCD filtering-

I can't answer this question, sorry.  Maybe others can help.

> FDEFs-
> I'm not sure how to approach searching the FDEFs for certain opcode
> patterns, in order to disable them.  Suggestions?

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.

> Vertical stem snapping-
> This is a weird one.  The MS engine is clearly doing snapping of
> vertical stems to fit symmetrically across pixels at certain ppems
> (13 - 15?), but other times not (17 - 20?).

Perhaps this depends on data in the `gasp' table?  Remember that some
fonts must be handled differently for certain ppem values (B/W versus
anti-aliased rendering).


    Werner