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

[Nikolaus Waxweiler]

@Werner: What keeps the subpixel hinting code from being turned on by 
default? And "stem width measured along the vertical axis" == stdHW?


> Thanks Nikolaus for working on this.  This is amazing!
I dream of the day where no one has to suffer crappy font rendering on 
Linux. If only distros would stop doing hintfull by default until 
hint-only-on-y is ready... Seriously, WHY doesn't everyone just do 
hintslight like Ubuntu does?

> One thing we need to figure out before this goes out is, this will be
> introducing drastic weight differences between unhinted, autohinted-light,
> autohinted-medium+, and bytecode-hinted.  That's not very good.  I think at
> least unhinted should get the same boost, unless turned off explicitly.
> Though I might be wrong.
I actually thought about that. The CFF engine darkens stems even when 
hinting is off. If I understand correctly (Dave, please correct me ;), 
the CFF engine computes the darkening values on load (the necessary 
stdHW/VW are stored in the PS dict) and uses them as deltas to shift 
points around when constructing paths. Better than emboldening the same 
glyphs again and again ;)

So I was thinking about refactoring the emboldening out into a kind of 
service that font drivers can use internally when they promise to hint Y 
only. But I know too little about FT's internals yet to judge if this is 
actually a good idea.

By the way, what do you mean by autohinted-light and autohinted-medium+? 
I thought there's just autohint (Y grid fitting only) and medium is an 
alias for full. This is one reason I would prefer fontconfig to say 
hintnative, hintauto, hintnone and get rid of the confusing 
hintslight/medium/full names and the autohint property. Seriously, 
people mix it up in every Linux font rendering discussion.

> Do you also modify advance width?
No, unless FT_Outline_Embolden() does that, then yes ;) It's intended as 
just a rasterization change. Yeah, I'd prefer it it was done universally.

> I'm still am of the opinion that this is a hack to work around lack of
> gamma-corrected blending AND lack of optical sizes.  But since it's in the CFF
> engine already, we might as well do it universally.
Actually, this is intended to be used with gamma-corrected blending ;) 
Uncorrected rendering looks rather burned out/blotchy/pixely.


> Be careful out there!
Hm, what should I do?

> How is speed?
I haven't measured that yet. Firefox with the pixman software rendering 
path (-> gamma-correct blending patch) feels a slight bit more sluggish, 
but that might be my mind playing tricks on me. How would I go about 
measuring this more objectively? Render an entire face to a buffer and 
take the time?


> 2.7 please!
I can already see mobs ravaging the forums because their fonts suddenly 
look fat and blotchy. Lets hope all the major toolkits turn on gamma 
correction until then (haha!).