Re: [ft-devel] [ttfautohint] stem width handling is now selectable

[vernon adams]

There is an aspect to all this which is maybe most relevant; how do these 
settings effect rendering across web browsers?
I've got a bit lost keeping up with what rendering the different browsers on 
Windows* use now. The default on Chrome seems to be best, as it sensibly seems 
to not use Cleartype above approx 40pp's. Firefox is equally good if the user 
toggles on the different DirectWrite render options 'under the hood'. Does 
anyone know for sure what uses what now?
I will try and do some extensive tests tomorrow; sans, serifs, win7, winXP, 
diff browsers, etc. I will prob add in Android too, as ttfautohint can effect 
fonts under Freetype too.

-vern


On 1 Jul 2012, at 20:13, Karsten Luecke wrote:

> When you say something like
> 
> > strong-stem-width=g gave a tiny (i think) better rendering
> 
> could you please explain what your definition of "better" is, plus a link to 
> comparison screenshots showing this setting vs the other setting? Stating 
> something is "better" is as useful as stating that today you feel fine.  :)
> 
> Karsten
> 
> 
> On 01.07.12 15:51, vern adams wrote:
>> Did a little testing using OpenSans Reg&  Bold under Win7 (cleartype&  
>> greyscale) and WinXP (cleartype&  greyscale) but, to be honest, i didn't see 
>> any difference :) except under Win7 there the `--strong-stem-width=g gave a 
>> tiny (i think) better rendering.
>> 
>> In theory, what difference should there be under which render settings?
>> 
>> -v
>> 
>> On 1 Jul 2012, at 12:49, Werner LEMBERG wrote:
>> 
>>> 
>>> From the documentation:
>>> 
>>> ### Stem Width and Stem Positioning
>>> 
>>> `--strong-stem-width=`*string*, `-w`\ *string*
>>> 
>>> :   ttfautohint offers two different routines to handle stem widths
>>>    and stem positions: 'smooth' and 'strong'.  The former uses
>>>    discrete values which slightly increase the stem contrast with
>>>    almost no distortion of the outlines, while the latter snaps both
>>>    stem widths and stem positions to integer pixel values as much as
>>>    possible, yielding a crisper appearance at the cost of much more
>>>    distortion.
>>> 
>>>    These two routines are mapped onto three possible rendering
>>>    targets:
>>> 
>>>    - grayscale rendering, with or without optimization for subpixel
>>>      positioning (e.g. Mac OS\ X)
>>> 
>>>    - 'GDI ClearType' rendering: the rasterizer version, as returned
>>>      by the GETINFO bytecode instruction, is in the range 36\<=
>>>      version<\ 38 and ClearType is enabled (e.g. Windows XP)
>>> 
>>>    - 'DirectWrite ClearType' rendering: the rasterizer version, as
>>>      returned by the GETINFO bytecode instruction, is>=\ 38,
>>>      ClearType is enabled, and subpixel positioning is enabled also
>>>      (e.g.  Windows\ 7)
>>> 
>>>    GDI ClearType uses a mode similar to B/W rendering along the
>>>    vertical axis, while DW ClearType applies grayscale rendering.
>>>    Additionally, only DW ClearType provides subpixel positioning
>>>    along the x\ axis.
>>> 
>>>    The command line option expects *string* to contain up to three
>>>    letters with possible values '`g`' for grayscale, '`G`' for GDI
>>>    ClearType, and '`D`' for DW ClearType.  If a letter is found in
>>>    *string*, the strong stem width routine is used for the
>>>    corresponding rendering target.  The default value is '`G`' which
>>>    means that strong stem width handling is activated for GDI
>>>    ClearType only.  To use smooth stem width handling for all three
>>>    rendering targets, use the empty string as an argument, usually
>>>    connoted with '`""`'.
>>> 
>>>    In the GUI, the option is split into three sets of radio buttons
>>>    to select the stem width routine for a given rendering target.
>>> 
>>> 
>>>  Please test and enjoy!
>>> 
>>> 
>>>     Werner
>