Re: [ft-devel] Autohinter: stem darkening, first rough prototype

[Werner LEMBERG]

> After a bit of testing, I think I know where the glitches come from.
> They are usually digits (0, 2, 8), overshoots (C) or other parts
> (lower belly of R, see the last two comparison shots) being snapped
> to 1 pixel above where they should be.  Emboldening probably lands
> the top of the stems outside their computed blue zone that doesn't
> know about the emboldening.  Funnily enough, it also fixes overshoot
> in DejaVu Serif's digits at various sizes.

This `fix' is purely accidental, unfortunately.  There is no guarantee
that you get similar well-looking results with other fonts.

> That's one of the difficulties I had with the emboldening support.
> I can't just modify aflatin.c and the others to embolden glyphs
> before analyzing them because the blue zones etc. are computed
> independently of pixel size and are fitted to a pixel size in a
> separate step, whereas emboldening depends on the pixel size.  I'd
> simply get wrong metrics.  I guess I either need to account for
> emboldening overshoot beforehand in af_*_metrics_init_blues or must
> implement/modify overshoot control in the hints-applier?

You might convert metric values from output space units back to font
units so that you get a correct fit for a particular size.  Or maybe
you extend the blue zone data structures with resolution-dependent
versions that you can adjust for emboldening.

> The other thing I thought about was implementing emboldening in the
> font drivers to have emboldening even without any hinting, like the
> CFF driver does by itself.  The way the autohinter currently works
> may make this difficult:
>
> 1. The autohinter seems to get the naked glyphs in font units from
>    the font driver for analysis (af_*_metrics_init_*) and rendering
>    (af_loader_load_g) and does the rest itself, so emboldened glyphs
>    of the font driver don't even reach the autohinter.

Correct.

> That's why, in ftview, going from native hinter to autohinter (press
> A, then B) loses emboldening.  I'd probably have to modify
> af_loader_load_g to take the normal outline as emitted by the font
> driver instead and apply hints to *that* outline.  But then the
> hinting machinery may need to know about what the font driver did to
> the outline to update its' inner size-independent model of the
> outline.

I have a problem to exactly understand what you mean with `emboldening
without any hinting'.  If you are using the auto-hinter, you *do*
hinting, and emboldening should be thus implemented by the auto-hinter
itself.  My point of view is that CFF's emboldening at smaller sizes
is already a kind of hinting, so it should stay within the driver.
[Of course, in case the code is really generic, I don't mind if it
gets moved to a `FreeType service' so that more than a single module
has access to it.]

> 2. OpenType/CFF and Type1 fonts specify stdVW/stdHW, but TrueType
> fonts don't.  If the TT driver or any other shouldn't depend on the
> autohinter to get at that information, it either needs to implement
> analyzers itself (ugh) or use e.g. the 50/75/110 heuristic Dave
> mentioned.  Or maybe the analysis part of the autohinter should be
> factored out?

The latter option is certainly the better one, but it is a non-trivial
task, I fear, since it affects almost everything from the auto-hinter
module.  So the first option is probably much easier to implement.


    Werner