Update CHANGES
file; other minor doc fixes.
This commit is contained in:
parent
69c3516c88
commit
90ecac4118
31
docs/CHANGES
31
docs/CHANGES
@ -79,13 +79,34 @@ CHANGES BETWEEN 2.10.4 and 2.11.0
|
||||
|
||||
- Improved Meson build support for the library.
|
||||
|
||||
- Meson support to build The FreeType demo programs.
|
||||
- Meson support to build the FreeType demo programs.
|
||||
|
||||
- `ttdebug` didn't show changed point coordinates (bug introduced in
|
||||
version 2.10.3).
|
||||
- A new demo program `ftsdf` is available to display Signed Distance
|
||||
Fields of glyphs.
|
||||
|
||||
- The graphical demos now work better in native color depth on win32
|
||||
and x11.
|
||||
- The `ftlint` demo program has been extended to do more testing of
|
||||
its input. In particular, it can display horizontal and vertical
|
||||
acutances for quality assessment, together with computing MD5
|
||||
checksums of rendered glyphs.
|
||||
|
||||
[The acutance measures how sharply the pixel coverage changes at
|
||||
glyph edges. For monochrome bitmaps, it is always 2.0 in either
|
||||
X or Y direction. For anti-aliased bitmaps, it depends on the
|
||||
hinting and the shape of a glyph and might approach or even reach
|
||||
value 2.0 for glyphs like 'I', 'L', '+', '-', or '=', while it
|
||||
might be lower for glyphs like 'O', 'S', or 'W'.]
|
||||
|
||||
- The `ttdebug` demo program didn't show changed point coordinates
|
||||
(bug introduced in version 2.10.3).
|
||||
|
||||
- It is now possible to adjust the axis increment for variable fonts
|
||||
in the `ftmulti` demo program.
|
||||
|
||||
- It is now possible to change the hinting engine in the `ftstring`
|
||||
demo program.
|
||||
|
||||
- The graphical demo programs work better now in native color depth
|
||||
on win32 and x11.
|
||||
|
||||
|
||||
======================================================================
|
||||
|
@ -73,6 +73,7 @@ I. Standard procedure
|
||||
formats)
|
||||
|
||||
src/raster/raster.c -- monochrome rasterizer
|
||||
src/sdf/sdf.c -- Signed Distance Field driver
|
||||
src/smooth/smooth.c -- anti-aliasing rasterizer
|
||||
|
||||
-- auxiliary modules (optional)
|
||||
|
@ -3445,7 +3445,8 @@ FT_BEGIN_HEADER
|
||||
*
|
||||
* which is known as the OVER operator.
|
||||
*
|
||||
* To correctly composite an antialiased pixel of a glyph onto a surface,
|
||||
* To correctly composite an anti-aliased pixel of a glyph onto a
|
||||
* surface,
|
||||
*
|
||||
* 1. take the foreground and background colors (e.g., in sRGB space)
|
||||
* and apply gamma to get them in a linear space,
|
||||
|
@ -84,15 +84,15 @@ FT_BEGIN_HEADER
|
||||
* @properties section.
|
||||
*
|
||||
*
|
||||
* **Hinting and antialiasing principles of the new engine**
|
||||
* **Hinting and anti-aliasing principles of the new engine**
|
||||
*
|
||||
* The rasterizer is positioning horizontal features (e.g., ascender
|
||||
* height & x-height, or crossbars) on the pixel grid and minimizing the
|
||||
* amount of antialiasing applied to them, while placing vertical
|
||||
* amount of anti-aliasing applied to them, while placing vertical
|
||||
* features (vertical stems) on the pixel grid without hinting, thus
|
||||
* representing the stem position and weight accurately. Sometimes the
|
||||
* vertical stems may be only partially black. In this context,
|
||||
* 'antialiasing' means that stems are not positioned exactly on pixel
|
||||
* 'anti-aliasing' means that stems are not positioned exactly on pixel
|
||||
* borders, causing a fuzzy appearance.
|
||||
*
|
||||
* There are two principles behind this approach.
|
||||
@ -108,7 +108,7 @@ FT_BEGIN_HEADER
|
||||
* sizes are comparable to kerning values and thus would be noticeable
|
||||
* (and distracting) while reading if hinting were applied.
|
||||
*
|
||||
* One of the reasons to not hint horizontally is antialiasing for LCD
|
||||
* One of the reasons to not hint horizontally is anti-aliasing for LCD
|
||||
* screens: The pixel geometry of modern displays supplies three vertical
|
||||
* subpixels as the eye moves horizontally across each visible pixel. On
|
||||
* devices where we can be certain this characteristic is present a
|
||||
@ -116,7 +116,7 @@ FT_BEGIN_HEADER
|
||||
* 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, and Latin type
|
||||
* designs. Even when the rasterizer uses greyscale antialiasing instead
|
||||
* designs. Even when the rasterizer uses greyscale anti-aliasing instead
|
||||
* of color (a necessary compromise when one doesn't know the screen
|
||||
* characteristics), the unhinted vertical features preserve the design's
|
||||
* weight and spacing much better than aliased type would.
|
||||
|
@ -290,7 +290,7 @@
|
||||
}
|
||||
|
||||
/* preset the bitmap using the glyph's outline; */
|
||||
/* the sdf bitmap is similar to an antialiased bitmap */
|
||||
/* the sdf bitmap is similar to an anti-aliased bitmap */
|
||||
/* with a slightly bigger size and different pixel mode */
|
||||
if ( ft_glyphslot_preset_bitmap( slot, FT_RENDER_MODE_NORMAL, origin ) )
|
||||
{
|
||||
|
Loading…
Reference in New Issue
Block a user