[Devel] Some news

[David Turner]

Hello everyone,

  I don't have much time tonight nor tomorrow to answer e-mails on the
  mailing lists. I'd like to make a few comments on recent events though:

   I. Graham's incremental loading changes:

     thanks to Graham for adding the code to support incremental font
     loading. It seems that with a growing number of active contributors
     to the source code, a "coding guidelines" would be very welcomed
     (though I don't know if I'll have the time to write it soon)

     However, I'd like to make a few remarks:

        - your changes have modified some high-level structures of
          the public API (e.g. FT_FaceRec, FT_Open_Args), and I
          believe that this is a *bad* thing.

          I'd prefer if we could move the changes of FT_FaceRec to
          the internal FT_Face_InternalRec structure (defined in "ftobjs.h")

          Also, it's possible to not touch the FT_Open_Args structure by
          using its "params" fields instead

     I have actually committed a new file named <freetype/ftincrem.h> that
     contains a _proposal_ new API to support incremental font loading within
     FreeType without touching a single-line of "freetype.h", as well as
     providing a more OOP-like interface (something I hope Graham will
     appreciate)

     Of course, this code isn't even compiled in a normal build and is
     provided as information for now. However, I'd like to receive Graham
     and other's comments on it, since I'd be extremely happy if the
     FT_CONFIG_OPTION_INCREMENTAL configuration macro wouldn't appear in
     any of the public header files provided with the font engine...


  III. New version of DocMaker:

     A new experimental version of DocMaker has been added to the CVS repository
     it uses Python regular expressions for some significant speed gains. 
Moreover,
     it adds some pretty nice new features (like full cross-reference, even in
     source fragments).

     It's not completely functional. More on this later...


  II. New release:

     I'd like to make a 2.1.3 release pretty quickly, since the current code
     contains noticeable improvements to both the Postscript and auto hinters 
:-)

     However, there are still a few things to fix to prevent nasty color fringes
     to appear with LCD-optimised text rendering under XFree86 4.2

     Another important point is the so-called "FT_Set_Hint_Mode" API. I've come
     to the conclusion that something like the following would be a good thing:

         typedef enum
         {
           FT_HINT_TARGET_MONO    = (1 << 0),  /* bit flags */
           FT_HINT_MODE_ANTIALIAS = (1 << 1),
           FT_HINT_MODE_OUTLINE   = (1 << 2)
         };

         typedef enum
         {
           FT_HINT_MODE_DEFAULT = 0,
           FT_HINT_MODE_MONOCHROME,
           FT_HINT_MODE_GRAY,
           FT_HINT_MODE_LCD_RGB,
           FT_HINT_MODE_LCD_VRGB,

           FT_HINT_MODE_EXPERIMENTAL_1  /* for experimentation */
           FT_HINT_MODE_EXPERIMENTAL_2  /* idem                */
         };

         void  FT_Set_Hint_Modes( FT_Library  library,
                                  FT_UInt     hint_targets,
                                  FT_UInt     hint_mode );

    The idea is that the hinting algorithm is likely to change depending on the
    final target surface, hence the introduction of the FT_HINT_TARGET_XXX 
constants

    The special value FT_HINT_MODE_DEFAULT correspond to an automatic hint mode 
selection
    within FT_Load_Glyph. So, if a monochrome bitmap is loaded, 
FT_HINT_MODE_MONOCHROME
    is selected, if it's an anti-aliased pixmap or an outline, 
FT_HINT_MODE_GRAY will be
    used

    Each hinter must support the relevant hint mode adequately, since it's not 
the
    user's business to know exactly what integer stem snapping means or not :-)

    more hint modes, including experimental ones can be introduced as well..

    The tricky part is that, for backwards compatible reasons, the 
FT_HINT_MODE_GRAY
    mode will force integer stem snapping to prevent color fringes in LCD 
modes. It
    is however hoped than in the near future, libXft will be able to call

       FT_Set_Hint_Modes( library,
                          FT_HINT_TARGET_ANTIALIAS | FT_HINT_TARGET_OUTLINE,
                          FT_HINT_MODE_LCD_RGB );

    directly. We will then be able to enable by default the latest 
optimisations for
    normal non-LCD displays


  Does all this makes sense ??

Best Regards,

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