Re: [ft-devel] gamma correction and FreeType

[Antti Lankila]

Dave Arnold <address@hidden> kirjoitti 8.11.2013 kello 22.19:

> Hi Antti,
> 
> On 11/7/2013 12:43 PM, Antti Lankila wrote:
>> Yes, I personally believe that ”optimal translation and scaling”, despite 
>> being an irritating parameter space search, would likely be the limit of the 
>> technique. More complicated strategies such as splitting the glyph box and 
>> stretching/shrinking the top/bottom halves slightly differently would still 
>> improve the alignment to pixel grid, but as previously noted, I have my 
>> dislike for solutions that imply distorting the outline. 
> The CFF hinting engine splits the glyph box into a number of horizontal 
> bands. Each split occurs at a declared hstem hint. You can think of the 
> mapping along the y-axis from the original font "character space" to the 
> "device space" as a piecewise linear function, where each piece is either a 
> stem or the space between two stems. So, it is really an extension of your 
> idea above, of splitting the glyph box.

Well, I guess I look pretty stupid right now. So it has been done. I admit that 
I’m starting to think that I will definitely want to take a good look at how 
CFF-based hinting actually looks like. This is a simple RTFM question, but I’ve 
no idea how to enable this code, or if it’s used by default, and so on. I will 
look into this on my linux virtual machine later.

>> I guess this means that a single glyph can have both darkened and undarkened 
>> stems. 
> No. I'm sorry I was not clear about this. The darkening amount is the same 
> for all parts of the glyph and indeed for all glyphs. It is computed from the 
> font dictionary entry for "standard stem width". (Actually, there are two 
> values: one for horizontal stems and one for vertical stems.) It is not 
> computed from actual stems.

Ah! Thanks a lot for clarification. This information of course could be used to 
build the alpha multiplier factor without having to make a complicated, error 
prone and time consuming rasterization and analysis.

— 
Antti