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

[Werner LEMBERG]

> 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.

[g = grayscaling, G = GDI ClearType, D = DW ClearType]

This is not correct.  Regarding effective horizontal resolution, we
have

  res(horz): g < G == D

due to the horizontal colour filtering of ClearType.  Note that GDI
ClearType doesn't use sub-pixel hinting, contrary to DW ClearType.

Regarding effective vertical resolution, however, we have

  res(vert): G < D == g

since GDI ClearType essentially uses B/W hinting along the vertical
axis.

> As a novice font-designer my opinion is that the current default
> produces and encourages broken fonts.

I don't understand why you consider this `broken'.  Please explain.

>> [...], 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.

I think it fits best: `G' means

  . full-pixel stem widths for GDI ClearType
  . discrete, possibly non-integer stem widths for both DW ClearType
    and grayscale hinting

>> 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.

What you want is exactly the opposite to what I consider best, namely
to make the font automatically adjust to the hinting environment.  In
general, I consider smooth stem widths superior to strong stem widths
since the overall shape distortions are reduced, together with a
better grayness.  The default setting makes it possible: strong stem
widths only in the GDI environment, where non-integer positioning
leads to extremely ugly results otherwise.


    Werner