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

[Werner LEMBERG]

> My initial idea was to do the calculations after
> af_face_globals_get_metrics() filled in
> 'AF_*Metrics->standard_weight'[1] and store them in
> AF_FaceGlobals->darken.  Until I noticed that they aren't redone on
> size changes because AF_FaceGlobals doesn't deal with size stuff.

Yes, the whole global glyph analysis happens in the font unit space.

> Then I thought about putting 'darken' into a sort of associative
> array like [12ppem -> FT_Pos(0.1), ...] and *then* store it in
> AF_FaceGlobals and trigger a recompute for a new size before
> FT_Outline_Embolden() if the new ppem can't be found in the array.
> That would make sure that the calculations are really only done once
> per size if the same face is used in multiple sizes or the client
> changes sizes back and forth.

I think this is not necessary.  As soon as you switch to a new size,
simply recompute the values.  As far as I can see, this isn't
computationally expensive.  Compare this to re-executing the `prep'
table data in the TrueType bytecode engine after a size change.

> Must investigate AF_GlyphHints and it's use to see if it's better
> suited than AF_FaceGlobals.  I think it gets scrubbed with each size
> change though?!

Yes.  Glyph hints are recomputed (i.e., aligned relative to the grid)
after a size change.

> And I still have to understand the glyph slot FT_Load_Glyph
> recursion stuff.  It still boggles my mind.

:) It's very simple: The auto-hinter needs unscaled, unhinted glyph
outline data for both the global and local processing, and the
recursive calls to FT_Load_Glyph do exactly this.  I believe that you
can ignore this completely for the emboldening issue.

> At least the dummy FT_Outline_Embolden() that I inserted after each
> FT_Load_Glyph() do what I want.  Yay!  Though I still don't know why
> I can't just do that once somewhere instead of after every
> FT_Load_Glyph() ;)

I think we should use the same approach as is done in Adobe's TrueType
engine, according to Dave: Apply emboldening only horizontally and
don't do horizontal hinting.  In other words, the emboldening will
happen only in the FT_RENDER_MODE_LIGHT auto-hinting mode.

For the global analysis, the auto-hinter loads a bunch of characters
to determine the blue zones, cf. function
`af_latin_metrics_init_blues'.  However, blue zones are derived from
vertical values; it is thus not necessary to call
`FT_Outline_Embolden_XY' in thus function.

A similar argument holds for `af_latin_metrics_init_widths': Only the
stem width measured along the vertical axis is used for light hinting.

As a result, I think that you need to call the emboldening function
only once, namely right after the `FT_Load_Glyph' call in function
`af_loader_load_g'.

> Speaking of random cleaning-up thoughts, what's the project's stance
> on making the TrueType bytecode fitter only fit on the Y axis by
> default?

The current subpixel hinting code should already be quite near to
that goal.

> Or would that touch the ClearType patents?

Certainly not.  You can't patent the omission of something if
everything else stays the same...


    Werner