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

[Dave Arnold]

Hi Nikolaus,

I would consider 1.8 to be "close" to 2.2. The exact value is not critical. But 
failing to apply a correction is equivalent to gamma 1.0, and does not work well.

It is unfortunate that gamma correction when compositing text is not part of 
FreeType. It is part of the graphics engine of the particular system. So some 
coordination is necessary between the components, and that's where things often 
break down. I don't know how it usually goes in Linux. For example, Google's 
Android sets a usable system default gamma, but OEMs are free to override it, 
and many do.

I do believe that stem darkening should be applied to TrueType. I consider the 
disparity between CFF and TT right now to be a serious problem. Adobe's 
proprietary TT rasterizer does apply stem darkening, but the base code is 
licensed from Microsoft, and cannot be contributed to an open source project.

A different approach is needed to do stem darkening in TrueType. In CFF, it is possible 
to apply darkening to the original outline in both horizontal and vertical directions and 
then adjust the hints so the final outline comes out properly hinted. In TrueType, it is 
not possible to adjust the native hints to account for darkening. I see two approaches 
that could work, though. One is to disable hints in the horizontal direction and just 
darken in that direction. This is an effective compromise and would be compatible with 
FreeType's "light" hint mode. It is also what Adobe does. The second approach 
would be to use FreeType's autohinter. Apply the stem darkening to the outline prior to 
running the authohinter. The result would be properly hinted and darkened.

Thanks.

-Dave

On 8/6/2015 7:53 AM, Nikolaus Waxweiler wrote:
> Hello list,
> I've been playing around with the CFF renderer again because font rendering is a dear 
> topic to me. What immediately stands out is that rendered fonts are much thicker than 
> what the autohinter puts out. This creates a somewhat strong contrast between local .otfs 
> and web fonts when browsing the net. Now, Dave Arnold said in an old mail to list that 
> "The stem darkening function assumes blending with a gamma close to 1.8".
>
> * What values/formula should I use with a gamma close to 2.2 or sRGB?
> * Shouldn't that be the default for a feature that's turned on by default? I 
> currently use Y1-Y4: 300, 200, 200, 0.
> * Arnold wrote that "gamma correction" is necessary. What part of the rendering 
> stack does that? And is it, in experience, implemented and working on the usual Linux 
> systems?
> * What's the state of stem darkening for the autohinter for e.g. TrueType 
> fonts? I see that Infinality has given up on maintaining his patch set. A 
> shared stem darkening would improve the coexistence of Adobe-CFF-rendered and 
> autohinted fonts.
>
> It saddens me that this great little piece of rendering code gets so little 
> publicity and (font) support from OSS communities... Shipping the URW35, DejaVu 
> and Liberation font families as properly hinted .otfs instead of .pfbs and 
> .ttfs would be a start.
>
> Regards,
> Nikolaus
>
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
> .