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

[Werner LEMBERG]

> Speaking of understanding, I'm trying to understand how darkening
> works in the CFF driver. So far, I have: cf2_computeDarkening()[1]
> is called twice per font face (CF2_Font =~ FT_Face?) upon
> initialization, once for vertical, once for horizontal stems, and
> calculates by how many pixels between 0 and 0.4 (default params) the
> font needs to grow in the X and Y direction.  These "deltas"/2 are
> then used to shift points around when turning the individual points
> of a glyph into a path, but before passing the path on to the rest
> of the hinting machinery.  Is that correct?

Let's wait for the definite answer from Dave :)

> I still have to understand the actual calculations and "character
> space" stuff, etc.  So the idea is, I outfit AF_ModuleRec_ with the
> no-stem-darkening and darkening-parameters attributes including
> getters and setters and use the same algorithm as
> cf2_computeDarkening() to come up with two FT_Pos that get used in
> FT_Outline_EmboldenXY() after each FT_Load_Glyph().  Correct?

Yes.

> Now to figure out how the autohinter is hooked up and invoked by
> font engines.

It's the `if ( autohint )' block in `FT_Load_Glyph'.
`hinting->load_glyph' then points to function `af_loader_load_glyph',
IIRC, which in turn calls `FT_Load_Glyph' by itself, but without
hinting.

> I need to figure out where to best place the darkening calculations
> so they are done just once per face/size.  And how to obtain
> stdVW/stdHW.

Yes :)

>> Mode `forced A' is strong auto-hinting, which hints horizontally
>> also, thus modifying the advance widths.  `forced B' (which is
>> identical to `B') is light auto-hinting that only hints along the
>> vertical axis, thus the advance widths are the same as if you
>> render the font unhinted.  `forced C' should have the same advance
>> widths as `forced A'.
> 
> Thanks for the explanation.  Unfortunately, 'forced A' and 'forced
> C' have slightly different metrics for Ubuntu-R.ttf and
> SourceSansPro-Regular.otf...

Ah, then I didn't have a close enough look.  Right now, I can't
explain the difference; maybe a rounding issue.

> By the way, I find this mode stuff confusing. Shouldn't it be
> 1. native-grid-fitting, autohinter-unless-tricky, no-grid-fitting
> 2. hint-X-and-Y, hint-Y-only
> 3. subpixel-none, subpixel-RGB, ...
> all as separate knobs with warnings if some combination doesn't
> work?

Well, ftview tries to mimick the FT_Load_Glyph arguments.  Please
proceed if you find a way to improve that!  It's not easy (at least
not for me) to get something better...

> [1]: It is slightly amusing that the CF2 stuff sometimes uses
> camelCasing while the rest of FT does_not.

This is not true.  Doing

  git grep '[A-Z][a-z]\+[A-Z]' -- '*.[ch]' | grep -v FreeType

I get almost 10000 hits.


    Werner