Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?

[Dave Arnold]

I'm happy to see all of this activity on stem darkening in the past week. It 
looks like excellent progress. I'm sorry it was a period when I was on vacation 
and away from email. Hopefully, most questions have been answered, but please 
let me know if there are outstanding issues that I can help with.

Here are some comments on questions that I saw in the thread that may help.

Yes, unhinted glyphs are darkened, too. The need to enhance contrast at small 
sizes exists whether or not the glyph is hinted. There is a separate control to 
turn off darkening, if that is needed.

The CFF code is designed to darken by different amounts in horizontal and vertical 
directions. The amount of darkening is determined by scaled stem width, so in a 
"high contrast" font, horizontal stems are thinner than vertical stems and need 
more darkening. In other words, the typographic contrast is reduced at small sizes. (This 
is similar to what is done for optical sizes.)

There is a CFF feature called "family blues" that limits we darken horizontal 
stems. I can provide more detail if you want, but this should not apply to TrueType.

As you noted, stdHW and stdVW are normally obtained from a CFF font dictionary. 
For TT, we (at Adobe) estimate stem width values based on the OS/2 weight 
class. We use three values, light (50/1000), regular (75/1000) and bold 
(110/1000).

If we darken TT outlines *after* hinting, we darken vertical stems only, and we 
apply less darkening than we do for CFF. This is because the nature of TT hints 
tends to darken horizontal stems at small sizes. (Consider a scaled horizontal 
stem that is less than one pixel wide. Typically, the hinting will snap it to a 
full integer pixel, effectively darkening it.) The TT darkening amounts were 
tuned experimentally so the combined darkening for CFF and TT looked similar.

If we darken TT outlines *before* hinting (e.g., by the autohinter) I'd expect 
horizontal and vertical darkening amounts could be computed separately. I'm not 
sure how to best estimate the stdHW or the contrast, though.

It is necessary to know the direction of the paths in order to darken by adjusting the 
path "outward".
While there is a recommended direction for both CFF and TrueType, some fonts 
don't always follow it. There are three cases:
1. All glyphs in the font have the wrong winding order. Some font converters 
fail to reverse path direction when moving from CFF to TT or back.
2. Some glyphs in the font have the wrong winding order. Perhaps some glyphs 
are produced as reflections?
3. Some glyphs contain inconsistent subpaths; some are correct and some are 
wrong.

The CFF rasterizer contains code to compute the winding order direction as the outline is 
traversed. If, at the end of the glyph outline, the winding order is as expected, then 
nothing extra needs to be done. If the winding order is wrong, then the glyph is 
re-rendered with darkening reversed. And the "expected" direction for this font 
is reversed. This means for case 1, above, only the first glyph pays a penalty. For case 
2, above, a few glyphs will be rendered twice. For case 3, (very rare) we ignore the 
problem; some glyph components will be lightened instead of darkened.

Thanks.

-Dave


On 8/23/2015 9:14 AM, Werner LEMBERG wrote:
> > > A similar argument holds for `af_latin_metrics_init_widths': Only
> > > the stem width measured along the vertical axis is used for light
> > > hinting.
> > Meaning, I'd have to modify AF_*Metrics to also compute stem widths
> > on the horizontal axis and use that for stemWidth?
> I don't think so.  Since we don't want emboldening for the `strong'
> hinting mode (actually, we *do* want that, but this is a much harder
> problem to solve), you don't have to change anything along the
> horizontal axis.
>
> > By the way, I can't directly access
> > e.g. AF_LatinMetrics->axis->standard_width from my
> > af_loader_compute_darkening() as I have only an AF_StyleMetrics to
> > go from..  Is there a reason why standard_width is specific to
> > writing class implementations of AF_StyleMetrics?
> I don't know.  Many of the details evolved over the time...
>
> > > The current subpixel hinting code should already be quite near to
> > > that goal.
> > And what keeps it from being made the default mode for the native TT
> > fitter?
> Behdad has answered that.  I haven't found time yet (and I probably
> won't in the very near future) to run a profiler on the code, fixing
> hot spots.  Maybe this is your follow-up project? :-)
>
> > Oh, and what's that about subpixel hinting in
> > af_loader_load_glyph()?
> For `light' hinting mode, you can ignore that.
>
>
>       Werner
>
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
> .