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