Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Dave Arnold]

First, a clarification on terminology. I've seen "vertical stem" used to mean either a horizontal stroke that is moved vertically by hinting or a vertical stroke that is moved horizontally by hinting. Nikolaus is using the former here. I am biased to use the latter, because it matches the operator definitions of Type 1 and CFF fonts. For example, the operator "vstem" declares a hint for a vertical stroke that may be moved horizontally to "snap" to a pixel boundary. In other words, an "I" is a single vertical stem and a hyphen is a single horizontal stem.

In another email, Nikolaus talks about adjusting advance width as a function of hinting. In my opinion this is a poor trade-off. It is much harder for a layout engine to do its work if advance widths are a function of size. This also defeats the PostScript philosophy of scalability and device independence. Think about WYSIWYG if layout is not linearly scalable. I've seen some systems that try to account for the fractional position of a glyph origin by adjusting its advance width. In such a system, a glyph advance cannot be known until all previous glyphs in a line of text have been hinted and positioned. Layout and rendering must be run simultaneously.

The motivation for adjusting advance width like this is to improve interglyph spacing. I think it is much better to keep advance widths linearly scalable and avoid horizontal snapping of vertical stems — "light" hinting.

Thanks.

-Dave

On 7/10/2017 7:40 AM, Nikolaus Waxweiler wrote:

The gif you posted looks like the FreeType hinter is in "full" mode and
snaps stems both vertically *and* horizontally. The Adobe hinter snaps
just vertical stems, or "light". Not sure if the Type1 hinter knows what
"light" is.

_______________________________________________
Freetype-devel mailing list
address@hidden
https://na01.safelinks.protection.outlook.com/?url="">
.