Re: [Devel] Adding options to the PS Hinter

[David Turner]

Hello Owen,

  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.

  As you'll see, auto-hinted text now looks much better in many
  cases. There are still some visible issues with serifed fonts
  like Times New Roman, Palatino, etc... but my latest
  experimentations have convinced me that these were due to some
  bugs in the outline analyzer (more precisely, in the way serif
  stems are detected and processed). I intend to work more deeply
  on the subject this week-end.

  I'd like to make a few additional remarks though:

  - I've added a new "waterfall" mode to "ftview". It's very
    handy to generate sample plates as well as check problems
    like stem un-eveness. You should be able to test it with
    the latest FreeType sources.
    

  - stem snapping will still be required for at least two
    well-known cases:

      * monochrome rendering:
         to avoid some really ugly artefacts, though this is
         still of minor importance as long as a new scan-line
         converter isn't written to support better drop-out
         control schemes.

      * LCD-optimized rendering (ClearType-like):
         the "gray-ish" borders of stems introduced by your
         changes and those within the auto-hinter tend to create
         colored fringes on the side of LCD-optimized AA text.
         I just tested this on my Debian KDE desktop, and this
         effect is _very_ visible.

    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.

    This means that integer stem-snapping with good results seem
    now possible. This still introduces un-eveness of diagonals
    but this effect seems a lot less noticeable with LCD rendered
    text anyway; I also believe that it could be handled by the
    monochrome rasterizer correctly with some cleverness I've
    been thinking for a long time right now (but couldn't really
    implement properly due to lack of time, as always)


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


  - your proposal of breaking 16-bit binary compatibility
    by changing the type of the "load_flags" parameter in
    FT_Load_Glyph from FT_UInt to FT_UInt32 or FT_ULong is
    a clever idea and I'm tempted to implement it right now.

    I'd like to know if anyone would feel concerned about
    this change. I doubt that it would change the binary
    interface of FreeType on any 32-bit operating system,
    right ??


  - finally, I do quantize the stem widths within the new
    auto-hinter, as well as strengthen "weak" stems to at
    least one pixel wide. This has the effect of higher
    contrast with about the same level of detail than
    your technique.

    In all cases, more experimentation is needed and will be
    performed. It seems that we might be able to completely
    forget about this patent non-sense in a relatively short
    time.. Good, really good :-) !!


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


  - 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, it's 3 AM, I'd better get to sleep now :-)

Thanks a lot,

- David Turner
- The FreeType Project  (www.freetype.org)

(sorry, no time to generate screenshots)