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
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
