Re: [Devel] default stem width and height for autohinting

[Vadim Plessky]

Hello David,

On Wednesday 07 May 2003 11:10, David Turner wrote:
|  Hello Vadim,
|
|  Vadim Plessky wrote:
[...]
|  > I think 'H' can be used for Vstem and Hstem values, and 'F'  - for
|  > HStem. Widths of both horizontal and vertical stems in 'O' and ('C',
|  > 'o', 'c') are higher than for 'H' (about 96 for H and 100 to 106 for O
|  > as VStem value in PostScript coordinates /1000 units/ for typical Sans
|  > font)
|
|  The problem is that these rules are not exactly valid on a large range
|  of fonts. Believe me, I've tested a lot of cases, and the 'o' is pretty
|  much the only stable option I could find (along with 'O')

Can you give any example (font name/family) where those values are unstable?
So far, Imostly sticked to own-made fonts, and I always tune HStem/VStem 
values hard-coded into PFB/OTF font manually.
It seems both PfaEdit and FontLab have algorithms for computtaion of standard 
Horiz/Vert. stem width (SetmSanpH, StemSnapV) being far from optimal.
I have following values in my Lucia Sans font (hard-coded by hand):
StdHW [62]
StdVW [88]
StemSnapH [62 79]
StemSnapV [88 94 100]

Vertical stem width for 'O' is 100, horizontal setm width - 79
'H'  Vertical - 94, horizontal - 79

On the other hand, if I use 'Guess" feature from PfaEdit, it suggests 
following values:
StdHW [20]
StdVW [94]
StemSnapH [20 62 79]
StemSnapV [88 94]

Which values are correct, in your opinion?
And what values I would get out of FreeType Autohinter (FT 2.1.4)?
// is ist posisble to add some command to 'ftview' so that you would apply 
autohinter even on pre-hinted font, and than inspect computed PS hints, 
including StemSnapH/V, StdHW, StdVW.
 
|
|  > On the other hand, I think autohinter should scan all Latin, Cyrillic,
|  > Greek Unicode ranges, and take weighted values for HStem/Vstem using
|  > those ranges. As far as Iknow, some font formats support different
|  > Hstem/Vstem values for different Unicode ranges 9in particular - fro CJK
|  > ranges).
|  > So indeed, Hstem/Vstem for CJK fonts should be calculated separatly .
|
|  The problem is that such processing takes a *lot* of time, relatively
|  speaking. Computing stem widths and heights is a lot more costly than
|  simply getting the bounding box of glyphs. The former is used to compute
|  the standard widths, while the latter is used to compute the blue zones.
|
|  Doing a statistical analysis of the glyphs would be a good thing, but
|  not necessarily something that would fit on-the-fly hinting. I'm more
|  interested by the performance of the auto-hinter on low-end processors
|  than on 1GHz beasts. That doesn't me it shouldn't be tried, but it's not
|  my priority, and we'll better need a way to get rid of this

There is a good option - to use pre-computed hinted values for specific 
Unicode ranges, and put those value sinto separate PostScript dictionaries 
(or similiar structures inside FreeType font object)

In my opinion, Latin/Greek/Cyrillic Alphabets can share one set of values.
Arabic/Hebrew probably need another one.
And CJK fonts can you thir sset of values.
If you can add such functionality into FreeType (so that FT would honour 
different StehH/W and BlueZone values for different alphabets) - I guess it 
would be possible to add necessary support to PfaEdit, too, so that it would 
be able to generate necessary entries in PFB/OTF fonts.

|
|  However, there are certain ways to make things better, like scanning
|  for certain script-specific letters to get the script-specific
|  standard widths. 

Yes, that's what I was talking about above.
And IMO, this can be done in Font Editor (PfaEdit) - doing such calculations 
in auto-hinter is indeed very time-consuming operation.

| Another way is to perform "offline" computations
|  and put them in external "hint files"
|
|  Regards,
|
|  - David Turner
|  - The FreeType Project (www.freetype.org)
|  _______________________________________________
|  Devel mailing list
|  address@hidden
|  http://www.freetype.org/mailman/listinfo/devel

Greetings,

Vadim
-- 

Best Regards,

Vadim Plessky
SVG Icons * BlueSphere Icons 0.3.0 released
http://svgicons.sourceforge.net