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

[Nikolaus Waxweiler]

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.

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?

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. 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.
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?

Thoughts?