[Devel] 2.1.3 release candidate 1 ready

[David Turner]

Hello,

  still not much time for e-mail, but I'd like to inform you
  that I've just tagged VER-2-1-3-RC1 in the CVS repository

  Note also that I finally chose not to use FT_Set_Hint_Mode
  to specify specific hinting optimizations. Instead, I've
  added new flags/constants in the FT_LOAD_XXX family,
  which are:

#define FT_LOAD_TARGET_(x)      ( (FT_Int32)((x) & 7) << 16 )
#define FT_LOAD_TARGET_MODE(x)  ((FT_Render_Mode)( ((x) >> 16) & 7 ))

#define  FT_LOAD_TARGET_NORMAL  FT_LOAD_TARGET_(FT_RENDER_MODE_NORMAL)
#define  FT_LOAD_TARGET_MONO    FT_LOAD_TARGET_(FT_RENDER_MODE_MONO)
#define  FT_LOAD_TARGET_LCD     FT_LOAD_TARGET_(FT_RENDER_MODE_LCD)
#define  FT_LOAD_TARGET_LCD_V   FT_LOAD_TARGET_(FT_RENDER_MODE_LCD_V)

  each FT_LOAD_TARGET_XXX constants has an impact on both
  *hinting* and *rendering*. Client applications simply need to
  tell what kind of final display surface they're generating the
  bitmaps for, and FreeType (or more precisely its hinters) are
  responsible for choosing the appropriate hint optimizations.

  This is much better than using explicit flags like
  FT_HINT_FLAG_NO_INTEGER_STEM which are generally hard to understand
  by non-font experts. (FT_Set_Hint_Mode is still there but does
  nothing and will soon disappear since it's not part of the official
  API)

  For your information, the current behaviour is
  the following:

    FT_LOAD_TARGET_NORMAL :: (the default)
      performs "smooth hinting" in both directions. the result is
      typically optimized for anti-aliased displays, but will generate
      acceptable monochrome bitmaps as well if you happen to use
      the FT_LOAD_MONOCHROME | FT_LOAD_RENDER flags (which still exist
      but only affect rendering, not hinting)

    FT_LOAD_TARGET_MONO ::
      snap stem widths to integers in both directions, which should
      give slightly better monochrome bitmaps. Using it with
      FT_LOAD_RENDER should always generate a bitmap (at least
      in theory ;-)

    FT_LOAD_TARGET_LCD ::
      snap vertical stem widths to integers, but smooth hints horizontal
      stems. This is optimized for horizontal RGB/BGR decimated displays
      like most LCD screens on the market today.

    FT_LOAD_TARGET_LCD_V ::
      a variant of FT_LOAD_TARGET_LCD for vertical decimated displays
      like rotated LCD screens (PDAs, RandR XFree86 extension, ...)

  Many constants have been renamed to use the UPPER_CASE convention,
  the old identifiers are still usable through macros, like:

   #define  ft_pixel_mode_mono   FT_PIXEL_MODE_MONO

  since we're talking about constants and enums, source and binary
  compatibilities are preserved.

  Note that there are now new values for FT_Render_Mode:

    FT_RENDER_MODE_NORMAL :: generate an 8-bit anti-aliased bitmap
    FT_RENDER_MODE_MONO   :: generate a 1-bit bitmap
    FT_RENDER_MODE_LCD    :: generate an 8-bit anti-aliased bitmap that
                             is 3 times wider than the original outline
    FT_RENDER_MODE_LCD_V  :: generate an 8-bit anti-aliased bitmap that
                             is 3 times taller than the original outline


  And corresponding new values for FT_Pixel_Mode:

    FT_PIXEL_MODE_GRAY  :: a.k.a. ft_pixel_mode_grays
    FT_PIXEL_MODE_MONO  :: a.k.a. ft_pixel_mode_mono
    FT_PIXEL_MODE_LCD   :: new mode (8-bit width*3)
    FT_PIXEL_MODE_LCD_V :: new mode (8-bit height*3)
    FT_PIXEL_MODE_GRAY2 :: a.k.a. ft_pixel_mode_pal2
    FT_PIXEL_MODE_GRAY4 :: a.k.a. ft_pixel_mode_pal4

  *NO* Filtering is performed by FreeType when it returns or
  renders to a bitmap in FT_PIXEL_MODE_LCD or
  FT_PIXEL_MODE_LCD_V, this must be done by the client
  application

  More details later on the subject.

Cheers,

- David