Re: [ft] ttfautohint strong-stem-width commandline default

[pippin]

On Sun, Feb 09, 2014 at 07:48:54AM +0100, Werner LEMBERG wrote:
> 
> > I am now running with --strong-stem-width='' for all invocations of
> > ttfautohint in my font generation pipeline. Which I think is a more
> > reasonable default than the current 'G'.
> > 
> > The vertical placement of horizontal stems seems to me to ba an
> > ortogonal to RGB subpixel vs Grayscale horizontal sub-pixel
> > rasterization.
> 
> I don't understand that paragraph.  Please reformulate.

ttfautohint only generates hints affecting vertical coordinates / snapping
horizontal stems closer to pixel boundaries. 'G' has the same vertical
resolution as 'g' and 'D' but a smaller effective horizontal resolution.  If
ttfautohint was modifying mostly the vertical stems instead of horizontal stems
I can see the motivation behind the current default.

At the moment it seems like either a left-over default from when the algorithm
was used for generating both horizontal and vertical hints - or it only serves
to illustrate the flexibility in configuration.

>
> > The two strings I think might be most useful are '' and 'gGD', is
> > there a reason for not just making this a boolean toggle?
> 
> Maybe.  However, this is not urgent IMHO.

As a novice font-designer my opinion is that the current default produces and
encourages broken fonts. Using either '' or 'gGD' as the default would save
operators of the tool time.

> > I didn't at first realize what the following in the --help implied.
> > 
> >   -w, --strong-stem-width=S  use strong stem width routine for modes S,
> >                              where S is a string of up to three letters
> >                              with possible values `g' for grayscale,
> >                              `G' for GDI ClearType, and `D' for
> >                              DirectWrite ClearType (default: G)
> 
> Well, yes, this is terse, but more explanations are given in the
> manual, ttfautohint.{html,pdf,txt}.

I haven't found anything explaining why 'G' has been picked as a default.

> > It took me some rounds of randomly juggling switches and knobs
> > throughout my font rendering stacks - trying to figure out why the
> > rendered shapes in chromium differed so much from gtk+, opera,
> > firefox and epiphany, turns out that the hints were different due to
> > it requesting/doing rendering with "grayscale vertical hints".
> 
> Can you suggest improvements to the manual or to the output of --help?

Yes - changing the default, then the setting could be ignored; unless more
advanced tuning is desired. Right now I have to always pass this argument to
get fonts that render similarly in different contexts.

/pippin