[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft] ttfautohint strong-stem-width commandline default
From: |
pippin |
Subject: |
Re: [ft] ttfautohint strong-stem-width commandline default |
Date: |
Sun, 9 Feb 2014 07:49:16 +0000 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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