s/sub-pixel/subpixel/.
This commit is contained in:
Werner Lemberg
parent
4a03f17449
commit
63aaf89cec
|
|
@ -6995,7 +6995,7 @@
|
|||
|
||||
2002-09-08 David Turner <david@freetype.org>
|
||||
|
||||
Various updates to correctly support sub-pixel rendering.
|
||||
Various updates to correctly support subpixel rendering.
|
||||
|
||||
* include/freetype/config/ftmodule.h: Add two renderers for LCD.
|
||||
|
||||
|
|
|
|||
|
|
@ -744,7 +744,7 @@
|
|||
|
||||
2013-01-16 David 'Digit' Turner <digit@google.com>
|
||||
|
||||
[truetype] Improve sub-pixel code.
|
||||
[truetype] Improve subpixel code.
|
||||
|
||||
This patches fixes many issues with the ttsubpix implementation.
|
||||
|
||||
|
|
|
|||
10
docs/CHANGES
10
docs/CHANGES
|
|
@ -286,7 +286,7 @@ CHANGES BETWEEN 2.7.1 and 2.8
|
|||
- FT_LOAD_TARGET_LCD is now a variant of FT_LOAD_TARGET_LIGHT;
|
||||
this should provide better rendering results.
|
||||
|
||||
- A mode to display light auto-hinting with sub-pixel positioning
|
||||
- A mode to display light auto-hinting with subpixel positioning
|
||||
has been added to `ftdiff'.
|
||||
|
||||
|
||||
|
|
@ -616,8 +616,8 @@ CHANGES BETWEEN 2.6.1 and 2.6.2
|
|||
|
||||
- The smooth renderer has been made faster.
|
||||
|
||||
- The `ftstring' demo program now supports sub-pixel rendering;
|
||||
use key `l' to cycle through the LCD modes.
|
||||
- The `ftstring' demo program now supports subpixel rendering; use
|
||||
key `l' to cycle through the LCD modes.
|
||||
|
||||
- The `ftstring' demo program now supports colour rendering; use
|
||||
the `space' key to cycle through various colour combinations.
|
||||
|
|
@ -3055,12 +3055,12 @@ CHANGES BETWEEN 2.1.3 and 2.1.2
|
|||
FT_LOAD_TARGET_MONO :: Hint and render for 1-bit displays.
|
||||
|
||||
FT_LOAD_TARGET_LCD :: Hint and render for horizontal RGB or
|
||||
BGR sub-pixel displays (like LCD
|
||||
BGR subpixel displays (like LCD
|
||||
screens). THIS IS STILL
|
||||
EXPERIMENTAL!
|
||||
|
||||
FT_LOAD_TARGET_LCD_V :: Same as FT_LOAD_TARGET_LCD, for
|
||||
vertical sub-pixel displays (like
|
||||
vertical subpixel displays (like
|
||||
rotated LCD screens). THIS IS STILL
|
||||
EXPERIMENTAL!
|
||||
|
||||
|
|
|
|||
|
|
@ -3065,7 +3065,7 @@ FT_BEGIN_HEADER
|
|||
*
|
||||
* Advance widths are rounded to integer values; however, using the
|
||||
* `lsb_delta' and `rsb_delta' fields of @FT_GlyphSlotRec, it is
|
||||
* possible to get fractional advance widths for sub-pixel positioning
|
||||
* possible to get fractional advance widths for subpixel positioning
|
||||
* (which is recommended to use).
|
||||
*
|
||||
* If configuration option AF_CONFIG_OPTION_TT_SIZE_METRICS is active,
|
||||
|
|
@ -3204,13 +3204,13 @@ FT_BEGIN_HEADER
|
|||
/* opacity). */
|
||||
/* */
|
||||
/* FT_RENDER_MODE_LCD :: */
|
||||
/* This mode corresponds to horizontal RGB and BGR sub-pixel */
|
||||
/* This mode corresponds to horizontal RGB and BGR subpixel */
|
||||
/* displays like LCD screens. It produces 8-bit bitmaps that are */
|
||||
/* 3~times the width of the original glyph outline in pixels, and */
|
||||
/* which use the @FT_PIXEL_MODE_LCD mode. */
|
||||
/* */
|
||||
/* FT_RENDER_MODE_LCD_V :: */
|
||||
/* This mode corresponds to vertical RGB and BGR sub-pixel displays */
|
||||
/* This mode corresponds to vertical RGB and BGR subpixel displays */
|
||||
/* (like PDA screens, rotated LCD displays, etc.). It produces */
|
||||
/* 8-bit bitmaps that are 3~times the height of the original */
|
||||
/* glyph outline in pixels and use the @FT_PIXEL_MODE_LCD_V mode. */
|
||||
|
|
|
|||
|
|
@ -111,9 +111,9 @@ FT_BEGIN_HEADER
|
|||
*
|
||||
* One of the reasons to not hint horizontally is antialiasing for LCD
|
||||
* screens: The pixel geometry of modern displays supplies three
|
||||
* vertical sub-pixels as the eye moves horizontally across each visible
|
||||
* vertical subpixels as the eye moves horizontally across each visible
|
||||
* pixel. On devices where we can be certain this characteristic is
|
||||
* present a rasterizer can take advantage of the sub-pixels to add
|
||||
* present a rasterizer can take advantage of the subpixels to add
|
||||
* increments of weight. In Western writing systems this turns out to
|
||||
* be the more critical direction anyway; the weights and spacing of
|
||||
* vertical stems (see above) are central to Armenian, Cyrillic, Greek,
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ FT_BEGIN_HEADER
|
|||
*
|
||||
* ametrics_x_scale ::
|
||||
* A 16.16 fixed-point number used to scale distance expressed
|
||||
* in metrics units to device sub-pixels. This is equivalent to
|
||||
* in metrics units to device subpixels. This is equivalent to
|
||||
* `face->size->x_scale', but for metrics only. Optional (parameter
|
||||
* can be NULL).
|
||||
*
|
||||
|
|
@ -123,7 +123,7 @@ FT_BEGIN_HEADER
|
|||
* mode, which always returns distances converted to outline units.
|
||||
*
|
||||
* You can use the value of the `x_scale' and `y_scale' parameters
|
||||
* returned by @FT_Get_PFR_Metrics to scale these to device sub-pixels.
|
||||
* returned by @FT_Get_PFR_Metrics to scale these to device subpixels.
|
||||
*/
|
||||
FT_EXPORT( FT_Error )
|
||||
FT_Get_PFR_Kerning( FT_Face face,
|
||||
|
|
@ -154,7 +154,7 @@ FT_BEGIN_HEADER
|
|||
*
|
||||
* @note:
|
||||
* You can use the `x_scale' or `y_scale' results of @FT_Get_PFR_Metrics
|
||||
* to convert the advance to device sub-pixels (i.e., 1/64th of pixels).
|
||||
* to convert the advance to device subpixels (i.e., 1/64th of pixels).
|
||||
*/
|
||||
FT_EXPORT( FT_Error )
|
||||
FT_Get_PFR_Advance( FT_Face face,
|
||||
|
|
|
|||
|
|
@ -76,9 +76,9 @@ extern void* _af_debug_hints;
|
|||
|
||||
typedef struct AF_WidthRec_
|
||||
{
|
||||
FT_Pos org; /* original position/width in font units */
|
||||
FT_Pos cur; /* current/scaled position/width in device sub-pixels */
|
||||
FT_Pos fit; /* current/fitted position/width in device sub-pixels */
|
||||
FT_Pos org; /* original position/width in font units */
|
||||
FT_Pos cur; /* current/scaled position/width in device subpixels */
|
||||
FT_Pos fit; /* current/fitted position/width in device subpixels */
|
||||
|
||||
} AF_WidthRec, *AF_Width;
|
||||
|
||||
|
|
|
|||
|
|
@ -404,7 +404,7 @@ typedef ptrdiff_t FT_PtrDist;
|
|||
/* need to define them to "float" or "double" when experimenting with */
|
||||
/* new algorithms */
|
||||
|
||||
typedef long TPos; /* sub-pixel coordinate */
|
||||
typedef long TPos; /* subpixel coordinate */
|
||||
typedef int TCoord; /* integer scanline/pixel coordinate */
|
||||
typedef int TArea; /* cell areas, coordinate products */
|
||||
|
||||
|
|
|
|||
|
|
@ -1219,7 +1219,7 @@
|
|||
* Theoretically, a glyph's bytecode can toggle ClearType's
|
||||
* `backward compatibility' mode, which would allow modification
|
||||
* of the advance width. In reality, however, applications
|
||||
* neither allow nor expect modified advance widths if sub-pixel
|
||||
* neither allow nor expect modified advance widths if subpixel
|
||||
* rendering is active.
|
||||
*
|
||||
*/
|
||||
|
|
|
|||
Loading…
Reference in New Issue