Re: [Devel] Adding options to the PS Hinter

[Owen Taylor]

David Turner <address@hidden> writes:

>   First of all, thanks a lot for your patches. Please notice
>   that I have commited them to the CVS, with the exception of
>   the last one.
> 
>   (by the way, your code is now in "src/pshinter/pshalgo3.c")
> 
>   your results are very pleasant and encouraging. I have started
>   investigating some ways to use similar ideas within the auto-hinter
>   and commited some source changes recently to the CVS repository.

[...]

It's nice to here glad that the ideas in the patch proved a useful 
starting point, rather than just having it as a solitary hack.

[...]     
> 
>   - stem snapping will still be required for at least two
>     well-known cases:
> 
>       * monochrome rendering:
[...]
> 
>       * LCD-optimized rendering (ClearType-like):
[...]

Exactly; what I'm offering currently in the font dialog I'm
working on is:

 A) no antialiasing / full hinting
 B) grayscale antialiasing / no integer stem
 C) grayscale antialiasing / full hinting
 D) subpixel antialiasing / full hinting

With C) basically always looking worse than B).
(http://people.redhat.com/otaylor/tmp/font-preferences.png)

>     Note however that it seems I've found a new stem snapping
>     algorithm that seems to avoid un-even stem widths and heights
>     relatively well.

Nice. I was thinking, for the postscript hinter, that something
like:

 - If after snapping to the StemSnapH/V widths, if the result
   is less than 0.5 pixels from the single "StdH/VW" value,
   use the StdH/VW value instead.

Might be appropriate. For the postscript hinter, one of the remaining
obvious defects with stem snapping is when you have standard
widths of say 80 and 90 units, and one gives you a 1 pixel stem,
the other a 2 pixel stem.
 
>   - An API to allow developers to tweak the parameters of a specific
>     hinter isn't necessarily a good thing (other than for debugging
>     and experimentation, of course).
> 
>     I think that a probably better idea is to let user specify
>     a specific "rendering-mode" they're interested in (e.g. 
>     "monochrome", "grayscale", "RGB-decimated", "BGR-decimated",
>     etc...) and let the hinter modules do their own magic to
>     adapt to these.
> 
>     It would also allow the addition of new rendering modes
>     in the future without asking application developers to
>     understand too many things about font hinting.
> 
>     For example, TV-specific rendering modes could be introduced
>     (on a TV, you want to absolutely _avoid_ vertical contrast due
>     to the flickering effect, and this can be adjusted by aligning
>     horizontal stems to *non-integer* positions instead)
> 
>     In the mean-time, an API like FT_Set_Hint_Mode isn't bad,
>     but I'd like to not make it part of the high-level API
>     for the beginning (we could put it in the "FT_XFREE86_H"
>     header file, for example).
 
I certainly agree that just giving the hinter the information
it needs to "do the right thing" is the best long-term
approach instead of constraining the details of the hinting
algorithm.

I have some experimental patches now to push the hinting style
options up through fontconfig/Xft/Pango/GTK+/gnome-control-center
and at every layer except for FreeType, I did it as:

 hintstyle = none/slight/medium/full

It's my observation that there is a fair bit of personal preference
as to the tradeoff between letterform accuracy and contrast.
It also depends somewhat on resolution and quality of output device.

>   - I don't have any official position regarding gamma. Your
>     gamma corrected images look worse than the original on
>     some of my monitors, and better on others; and that's
>     even when I apply all sorts of gamma corrections to
>     "rectify" things.
> 
>     My opinion is that the average user is going to have a
>     *very* hard time trying to guess or compute it's monitor
>     gamma or color gamut anyway, as well as the adequate
>     parameter to the X Server; and the complexity involved
>     to implement all of this might not be necessarily
>     something important to most people.
 
It's certainly not an area I feel that I've gotten a
firm answer in; or results that "just look better". But: 

 a) While there may be trouble in guessing the user's gamma
    value, 1 is definitely not right.

 b) Without gamma correction, white on black AA text does 
    look ugly.

So I'm not ready to give up on the idea yet.
 
>   - By the way, could you re-generate your last patch against
>     the latest CVS sources. I won't make anymore modifications
>     to the Postscript hinter until I receive something from
>     you..

OK, I'll try to get that done today. 

Regards,
                                        Owen