Re: [ft-devel] State of TrueType interpreter v38 and up?

[Nikolaus Waxweiler]

> It must
>
>    (a) ignore changes of the horizontal advance widths due to
>        hinting instructions (not implemented yet), and
>
>    (b) ensure that all instructions behave correctly even if the
>        horizontal resolution is increased (this is ClearType
>        compatibility mode, already implemented).

Ah, okay :) is (a) so complicated or is it that simply nobody did the 
work yet? And regarding your other post dealing with DWRITE equivalents, 
I think FT then with the above only ever does 
DWRITE_RENDERING_MODE_NATURAL_SYMMETRIC, which is probably what we want 
for light mode.

> No. This is what *effectively* happens, due to the strongly
> increased horizontal resolution. However, at least in `native' mode,
> you can still enforce non-integer positions along the x axis.

> Such a mode doesn't exist in the MS engine. However, Adobe's
> modified TT engine essentially hints only along the y axis, if I've
> understood Dave Arnold correctly, replacing x axis hints with
> emboldening.

How complicated. So I guess ClearType
- without stem darkening: let font modify x-coordinates at will but 
ignore modifications to advance width
- with stem-darkening: nop everything that deals with x-coordinates and 
embolden just the x-axis? Dave?
The latter would make backwards compatibility irrelevant because we 
would only honor Y-hints anyway, right?

> ... the MS approach is superior IMHO.  It
>
>    (a) elegantly circumvents many problems due to the extreme
>        difference between horizontal and vertical resolution – it
>        basically makes the compatibillity mode redundant, and
>
>    (b) the increased resolution is around 10 times in both horizontal
>        and vertical direction, compared to a threefold horizontal
>        resolution increase of FreeType.

Hm. Something for a hypothetical FreeType 3 :) ClearType patents should 
have run out by then ;)