freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] Autohinter: stem darkening, first rough prototype


From: Dave Arnold
Subject: Re: [ft-devel] Autohinter: stem darkening, first rough prototype
Date: Thu, 27 Aug 2015 13:45:34 -0700
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

On 8/27/2015 8:44 AM, Alexei Podtelezhnikov wrote:
On Thu, Aug 27, 2015 at 10:46 AM, Nikolaus Waxweiler <address@hidden> wrote:
The look of the function is documented and it blows my mind. I want to
know what they smoked. You simply cannot find such beasts in nature
short of quantum mechanics. I simply cannot trust that it was
optimized rationally by looking at the rendering results, because
optimizing in 8-dimensional space is not for humans and their eyes. My
head explodes when I look at this function and I have this feeling in
my mouth. I am scared and I cannot dare to touch it. God bless those
who want to tune it.

Could you implement your curve in the context of
af_loader_compute_darkening() and send it to me? Because my brain currently
doesn't grok the math behind character and device-pixel space conversion ;D
Then we can compare and see what's better :)

The simplest is to check if you see any difference with this set of parameters:

#define CFF_CONFIG_OPTION_DARKENING_PARAMETER_X1   0
#define CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y1   500

#define CFF_CONFIG_OPTION_DARKENING_PARAMETER_X2  2000
#define CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y2   0

#define CFF_CONFIG_OPTION_DARKENING_PARAMETER_X3  2000
#define CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y3   0

#define CFF_CONFIG_OPTION_DARKENING_PARAMETER_X4  2000
#define CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y4     0

_______________________________________________
Freetype-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/freetype-devel
.

This is not as complicated as the API makes it appear.

The original implementation was intended to be internal, not exposed the 
clients. But when the new CFF rasterizer was first released in FreeType, some 
people wanted to tune the amount of darkening. This may have been due to 
personal preference, but I suspect that the common lack of proper gamma 
correction and the difference between darkening CFF and not darkening TT led to 
this.

When the API was added to give clients control of the darkening amount, a very 
general purpose mapping was made between the internal implementation and the 
external API. In reality, there are many constraints on the 8 exposed values; 
they are not independent variables! Alexei is quite correct that an 
8-dimensional space would be ridiculous.

I think a 1-dimensional control of the darkening amount would be sufficient. 
Some time ago I wrote:
I'd propose a single value from 0 to 1 (or maybe 0 to 100) that would linearly scale y1, y2 and y3 together, between zero and the default. I would make x1, x2, x3, x4 and y4 constant.
But we are now constrained by compatibility.

By the way, the current default (Adobe and FreeType) for CFF can be expressed 
as 400,275,275 (y1,y2,y3).
For comparison, the reduced darkening for TT (in Adobe's product) is 
300,250,250.

When it comes to testing, there is a multi-dimensional nature to the problem. 
One dimension is the font style (e.g., serif, sans, script, etc.). The second 
dimension is the size. Waterfall documents with each line containing the same 
text but at incremented size are handy for this. And the third dimension is the 
typographic weight. Families with fine gradations, like regular, medium, 
semibold, are useful for this.

Thanks.

-Dave




reply via email to

[Prev in Thread] Current Thread [Next in Thread]