Re: [ft-devel] gamma correction and FreeType

[Dave Arnold]

Hi Antii,

Thank you for the interesting page. The text looks good, but I think we differ a bit in our "hinting philosophy" :-) .

I completely understand why many people have an aversion to the way hints can distort a typeface design. I've seen examples where you might be fooled into thinking the hinted font was a different font altogether. But, personally, I dislike "fuzzy" fonts. I also value consistency. To me, fonts that are fuzzy at some sizes and sharp at others are even worse. I've talked to web designers about their choices and heard them argue that they chose a 13.5 pixel font because it had a sharper x-height than 13. This is wrong. Designing in pixels is not scalable. It's better if all sizes are as consistent as possible, because you (the designer) may not have control of the final ppem on the user's machine.

The philosophy of hinting in the Adobe CFF rasterizer is to use as little as possible. Horizontal stems in alignment zones are strongly hinted, because sharp alignment zones help in reading Latin-based text. Other horizontal stems are hinted to produce the least possible movement (and to avoid collisions). Vertical stems are not hinted at all. This is because interglyph spacing and kerning are more important to readability than sharp vertical stems (again, this is for Latin-based text). This is very similar to the light mode of the FreeType autohinter. Finally, stem widths are not modified. That is, they are not "snapped" to integer widths. This is one of the advantages of rendering antialiased text. Stem snapping was invented for bilevel/monochrome text, where it is necessary to achieve consistent stem widths.

Some comments on your approach are below.

Thanks.

-Dave

On 11/6/2013 11:28 PM, Antti Lankila wrote:

Antti Lankila <address@hidden> kirjoitti 5.11.2013 kello 23.31:

I humored myself and spent this evening reminding myself how to use FT and libpng. Here is the result:

https://bel.fi/alankila/lcd/font/

I’ve been thinking of using the full 6-bit fixed point glyph advance and kerning, and completely get rid of the pixel grid, but anyway, this is what it looks like when text is rendered to subpixel grid.

One more update.

Since I hate hinting and munging of glyph outlines for philosophical reasons, I’ve been experimenting with ways to get the result of hinting (crisp fonts) without actually doing any.

I updated that page with an approach that applies a per-glyph translation which is calculated in such a way that it should result in symmetric antialiasing around stems, to the degree it is possible with the approach I chose. In fact, this translation is calculated in two ways:

- one face and size -global y offset, calculated over all the glyphs in the face, to produce the best contrast available for horizontal stems

Do you find that the y-offset is dominated by stems at the baseline? I'd guess these were the most common. I like the use of a global offset to keep the baseline straight.

I'd guess that most Latin characters are influenced by two alignment zones. E.g., baseline and x-height, or baseline and cap-height. This suggests that an adjustable scale factor would help to match both. (I think there is such a mechanism in FreeType autohint.)

- per glyph x offset, which just enhances the vertical stems. Since kerning and glyph placement is per subpixel, it causes only very minor bit of horizontal jitter, too little to be noticeable to me.

Are you saying that the x-offset is limited to +- 1/6 pixel because you're assuming vertically striped LCD? Would you disable the x-translation for horizontally striped or grayscale rendering?

The offsets are calculated from the vector outline by looking at vertical and horizontal edges, and noting which 1/64th pixel offset they fall on, and then applying a translation that tries to move the average edge as close to the full pixel boundary as possible. (I’m personally not yet quite convinced if it finds the actually optimal translation though.)

I’d also like to implement the darkening somehow without touching the glyph outline, but the best idea I have so far is to simply use a multiplier on the alpha bitmap (which should of course be calculated somehow, not just specified as some kind of magical number). For now, I leave the 0.5 px outline bolding because it is just one number and should ”optimally” enhance glyphs to full alpha range in small glyph sizes, and degrades gradually to irrelevance if the rendering size is increased.

You are using a constant darkening amount. I think Apple does this, too.

The design goals in the Adobe CFF rasterizer are to minimize distortion, and darkening is a form of distortion. The darkening amount is variable because light fonts lose contrast more readily than bold fonts. And at larger sizes (above about two pixel stems) no darkening is needed, so no distortion is needed.

I would avoid adjusting the alpha map to achieve darkening. I don't see how to do it without distorting the perceived shape. How would you darken an edge pixel whose alpha value is 1.0? When you embolden the outline, you darken that pixel by turning on a neighbor.

— 

Antti