Re: [ft-devel] broken hinted DejaVuSans et 4

[Werner LEMBERG]

> > It seems that the execution of [glyph uni277C's] bytecode at that
> > size somehow influences rendering of other glyphs, but I have no
> > idea how this is possible at all.  Valgrind shows nothing, BTW.

I've now debugged this issue.

> The bytecode for DejaVu Sans' uni277C in svn in:
> 
> SVTCA[y-axis]
> PUSHW_3
>  17
>  3
>  3
> CALL
> [...]

This CALL instruction invokes a subroutine which is causing the
problem:

  MPPEM
  LT
  IF
    DUP
    PUSHB_1
      253
    RCVT
    WCVTP    <----
  EIF
  POP

Note that the marked instruction writes to the CVT, and later glyphs
use this modified value.  It is not described in the OpenType
specification what to do in this situation.

CVT values in a TrueType font are normally modified in the `prep'
table to adapt them to the current device resolution.  If the
resolution changes, the `prep' table is executed again.

However, what happens if there is a WCVTP or WCVTF instruction within
a glyph's bytecode to modify a CVT entry?

I can imagine three possible solutions.  Let's assume that we have
WCVTP and/or WCVTF commands in glyph A.

  1. WCVTP and WCVTF are allowed and are applied globally.  As a
     consequence, rendering glyph A might influence the shape of any
     other glyph.

  2. WCVTP and WCVTF are allowed and are applied locally.  All
     modified CVT entries are restored after rendering of glyph A.

  3. WCVTP and WCVTF are ignored if found outside of the `prep' table.

IMHO, option 1 is bad, and that options 2 and 3 are OK.  I favour
option 3 since it is most convenient to implement.  Right now,
FreeType does option 1, and we should change that...

I've just written an email to Greg Hitchcock, asking for
clarification.


    Werner