Re: [ft-devel] New `slight' auto-hinting mode

[Alexei Podtelezhnikov]

Hi all,

My arguments follow (from my personal communications with Werner)...

> (1a) The user calls either `FT_Request_Size' or `FT_Set_Char_Size'
> (1c) The internal function `FT_Request_Metrics' sets up values in the
>      `FT_Size_Metrics' structure: It first computes `x_scale' and
>      `y_scale' (fractional values in 16.16 format), then `x_ppem' and
>      `y_ppem' (which are integers)
> (1d) Depending on a flag in the `head' table of a TTF (which is
>      basically always set),
>      Then the function recomputes `x_scale' and `y_scale' using the
>      integer `x_ppem' and `y_ppem' values

This rounding essentially means that only discrete x_scale and y_scale
values were effectively set regardless of what user requested. For
example, asking for 8 points at 96 dpi would produce x_scale and
y_scale values corresponding to 8.25 points. Asking for 10 points at
96 dpi  would produce scaling to 9.75 points actually. At 96 dpi the
following discrete sizes would result: ... ,8.25, 9, 9.75, 10.5,
11.25, 12... Anyway, without user knowledge the output was a bit
larger or smaller then requested, which is a problem and the root
cause of some WYSIWYG bugs...

> (2c) ...The `light' auto-hinter takes its scaling values from the
>      top-level size metrics structure.  However, (1e) changes both the
>      vertical *and* horizontal scaling for TTFs; this means horizontal
>      metrics change for `light' auto-hinting, too.

Of course, fixing this will result in visible changes because users
get true unrounded size exactly as they requested. There will be
people who will not like the change, but, hey, they can always request
the old actual size from the discrete spectrum (e.g., see above) if
they are nostalgic. I do not think we need a new hinting mode for the
disenchanted. At most, we can offer them a property
"af_force_integer_ppem" for them.

> Basically, the `light' mode is completely equivalent to `slight'...
> Using the
> `lsb_delta' and `rsb_delta' fields, it is also possible to derive
> fractional advance widths in `light' mode: Using the values from
> `face->glyph', we have
>
>   frac_adv_width = advance.x + (lsb_delta - rsb_delta)

If somebody was correctly using the deltas for text layout, switching
to fractional advance in light mode is totally seamless, because
lsb_delta is always 0 in light mode (unless warping, which is another
topic). Again there is no need for a new mode.

Alexei