[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Devel] 2.1.3 release candidate 1 ready
From: |
David Turner |
Subject: |
[Devel] 2.1.3 release candidate 1 ready |
Date: |
Fri, 30 Aug 2002 01:39:16 +0200 |
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
- [Devel] 2.1.3 release candidate 1 ready,
David Turner <=