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