Re: [ft-devel] Experimental: v38 interpreter with minimal backwards compatibility mode and linear advance widths

[Werner LEMBERG]

Just starting to have a look, but I stopped immediately:

>  #ifdef TT_CONFIG_OPTION_SUBPIXEL_HINTING
>      TT_Driver  driver = (TT_Driver)FT_FACE_DRIVER( face );
>  #endif
> +    TT_Driver  driver = (TT_Driver)FT_FACE_DRIVER( face );

What's this?  If the #ifdef is true, you declare and set `driver'
twice...

> -    /* adjust advance width to the value contained in the hdmx table */
> -    /* unless FT_LOAD_COMPUTE_METRICS is set                         */
> -    if ( !face->postscript.isFixedPitch                    &&
> -         IS_HINTED( loader->load_flags )                   &&
> +    /* Adjust advance width to the value contained in the hdmx table
> +     * unless FT_LOAD_COMPUTE_METRICS is set. Interpreter v38 uses subpixel
> +     * hinting and indicates subpixel positioning and therefore ignores any
> +     * changes to the horizontal advance width. XXX: does this clash with any
> +     * non-bytecode-advance-width-changing-feature? */
> +    if ( driver->interpreter_version != TT_INTERPRETER_VERSION_38 &&
> +         !face->postscript.isFixedPitch                           &&
> +         IS_HINTED( loader->load_flags )                          &&
>           !( loader->load_flags & FT_LOAD_COMPUTE_METRICS ) )

This is not correct.  Even within the MS interpreter, the advance
width *can* be changed if in non-backwards-compatibility mode (i.e.,
`native ClearType hinting').  The next step however, the MS
rasterizer, then ignores the changed advance width, which is the
reason the user can't see changes to it.

I suggest that we allow advance width changes in native ClearType
hinting mode, being `better' than MS :-) Applications like web
browsers can still override this by using the unchanged advance
widths.

Regarding the XXX: Only bytecode can change the advance width, AFAICR.

A review of the remaining patch will follow within a few days, I hope.


    Werner