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.