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

[Dave Crossland]

Hi

On Aug 25, 2015 8:21 PM, "Dave Arnold" <address@hidden> wrote:
>
> 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.

Thanks for all this, it's great stuff :)

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

I'm confused about this. If a single style family had a weight class of 400 but it's stems are much more/less than 75, will that font be darkened/lightened too much?

> 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
>> .
>>
>
>
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/freetype-devel