Fri 06 Nov 2015 05:48:04 AM UTC, comment #6:
This patch looks better, thanks!
However, I think using the value `yMax - yMin' is problematic, since this might include glyphs not used for writing a script but covering a font's generic symbols of arbitrary size. We probably need a more advanced test...
What about this: If we have (reasonable) blue zones for ascenders and descenders of the given script, take the maxima, then compare. Otherwise use the EM size for comparison.
And please enclose the `else' part into `#ifdef FT_DEBUG_LEVEL_TRACE ... #endif' to avoid clang warnings.
|
Mon 02 Nov 2015 08:48:46 PM UTC, comment #3:
In principle, I like the idea to limit the changes to two pixels, and in fact this is what I also initially wanted to implement :). But the autohinter seems to work a bit different than I expected.
My understanding is that there are two classes of blue zones:
- Those that are flagged with AF_BLUE_PROPERTY_LATIN_X_HEIGHT, like "xzroesc" in standard latin.
- And the rest.
For both, blue zones are detected in af_latin_metrics_init_blues, oblivious of a specific scaling to device units.
Then af_latin_metrics_scale_dim uses the first class of characters, with the AF_BLUE_PROPERTY_LATIN_X_HEIGHT property, to scale the whole character class, such that the upper end of, e.g., "xzroesc" snap to the grid. The central assumption here in the code is that the corresponding glyphs of these characters do not have a substantial extent beneath the baseline. This is where the math fonts fail, since there the baseline is close to the upper end of the glyph, such that the code always tries to snap this small part to the grid, which results in the large scaling factor.
In a last step the hints are applied, including also the remaining blue zones. Without having looked at this code in detail, it seems that the code is quite aware of the surrounding grid and probably respects the required two pixel property.
In any case, these two steps are superpositional and if there would be a bug in both, they probably would need to be fixed separately. The submitted patch is a first attempt to fix the scaling issue in the first part. Nonetheless, there might still be a smarter fix, which may also work for other character classes than latin, but I probably lack the necessary knowledge about the code :) If you have any idea for a better criteria than comparing the extent above and below the baseline, I'm open for suggestions.
|
Mon 02 Nov 2015 06:08:33 AM UTC, comment #2:
Thanks for the patch, but this is not what I had in mind, since it only solves a special case. What I want is ignoring all results that change the glyph height or depth by more than a given threshold, which is around 2.0 pixels (or even less). Ideally, the auto-hinter should recognize such problems as early as possible, e.g., by ignoring blue zones that would lead to such large distortions, or applying a too large or too small x-height scaling.
Can you work on that?
|
Tue 13 Oct 2015 09:02:11 AM UTC, original submission:
In case of invalid or buggy fonts, prevent the auto-hinter from distorting the glyphs too much, cf.
https://bugs.freedesktop.org/show_bug.cgi?id=91829
`Invalid' here means cheating to the auto-hinter, e.g., mapping character `A' to glyph `udieresis', or having not enough characters to derive reliable blue zones.
|