Werner Lemberg pushed to branch master at FreeType / FreeType
Commits:
-
90ecac41
by Werner Lemberg at 2021-06-30T10:23:42+02:00
5 changed files:
- docs/CHANGES
- docs/INSTALL.ANY
- include/freetype/freetype.h
- include/freetype/ftdriver.h
- src/sdf/ftsdfrend.c
Changes:
... | ... | @@ -79,13 +79,34 @@ CHANGES BETWEEN 2.10.4 and 2.11.0 |
79 | 79 |
|
80 | 80 |
- Improved Meson build support for the library.
|
81 | 81 |
|
82 |
- - Meson support to build The FreeType demo programs.
|
|
82 |
+ - Meson support to build the FreeType demo programs.
|
|
83 | 83 |
|
84 |
- - `ttdebug` didn't show changed point coordinates (bug introduced in
|
|
85 |
- version 2.10.3).
|
|
84 |
+ - A new demo program `ftsdf` is available to display Signed Distance
|
|
85 |
+ Fields of glyphs.
|
|
86 | 86 |
|
87 |
- - The graphical demos now work better in native color depth on win32
|
|
88 |
- and x11.
|
|
87 |
+ - The `ftlint` demo program has been extended to do more testing of
|
|
88 |
+ its input. In particular, it can display horizontal and vertical
|
|
89 |
+ acutances for quality assessment, together with computing MD5
|
|
90 |
+ checksums of rendered glyphs.
|
|
91 |
+ |
|
92 |
+ [The acutance measures how sharply the pixel coverage changes at
|
|
93 |
+ glyph edges. For monochrome bitmaps, it is always 2.0 in either
|
|
94 |
+ X or Y direction. For anti-aliased bitmaps, it depends on the
|
|
95 |
+ hinting and the shape of a glyph and might approach or even reach
|
|
96 |
+ value 2.0 for glyphs like 'I', 'L', '+', '-', or '=', while it
|
|
97 |
+ might be lower for glyphs like 'O', 'S', or 'W'.]
|
|
98 |
+ |
|
99 |
+ - The `ttdebug` demo program didn't show changed point coordinates
|
|
100 |
+ (bug introduced in version 2.10.3).
|
|
101 |
+ |
|
102 |
+ - It is now possible to adjust the axis increment for variable fonts
|
|
103 |
+ in the `ftmulti` demo program.
|
|
104 |
+ |
|
105 |
+ - It is now possible to change the hinting engine in the `ftstring`
|
|
106 |
+ demo program.
|
|
107 |
+ |
|
108 |
+ - The graphical demo programs work better now in native color depth
|
|
109 |
+ on win32 and x11.
|
|
89 | 110 |
|
90 | 111 |
|
91 | 112 |
======================================================================
|
... | ... | @@ -73,6 +73,7 @@ I. Standard procedure |
73 | 73 |
formats)
|
74 | 74 |
|
75 | 75 |
src/raster/raster.c -- monochrome rasterizer
|
76 |
+ src/sdf/sdf.c -- Signed Distance Field driver
|
|
76 | 77 |
src/smooth/smooth.c -- anti-aliasing rasterizer
|
77 | 78 |
|
78 | 79 |
-- auxiliary modules (optional)
|
... | ... | @@ -3445,7 +3445,8 @@ FT_BEGIN_HEADER |
3445 | 3445 |
*
|
3446 | 3446 |
* which is known as the OVER operator.
|
3447 | 3447 |
*
|
3448 |
- * To correctly composite an antialiased pixel of a glyph onto a surface,
|
|
3448 |
+ * To correctly composite an anti-aliased pixel of a glyph onto a
|
|
3449 |
+ * surface,
|
|
3449 | 3450 |
*
|
3450 | 3451 |
* 1. take the foreground and background colors (e.g., in sRGB space)
|
3451 | 3452 |
* and apply gamma to get them in a linear space,
|
... | ... | @@ -84,15 +84,15 @@ FT_BEGIN_HEADER |
84 | 84 |
* @properties section.
|
85 | 85 |
*
|
86 | 86 |
*
|
87 |
- * **Hinting and antialiasing principles of the new engine**
|
|
87 |
+ * **Hinting and anti-aliasing principles of the new engine**
|
|
88 | 88 |
*
|
89 | 89 |
* The rasterizer is positioning horizontal features (e.g., ascender
|
90 | 90 |
* height & x-height, or crossbars) on the pixel grid and minimizing the
|
91 |
- * amount of antialiasing applied to them, while placing vertical
|
|
91 |
+ * amount of anti-aliasing applied to them, while placing vertical
|
|
92 | 92 |
* features (vertical stems) on the pixel grid without hinting, thus
|
93 | 93 |
* representing the stem position and weight accurately. Sometimes the
|
94 | 94 |
* vertical stems may be only partially black. In this context,
|
95 |
- * 'antialiasing' means that stems are not positioned exactly on pixel
|
|
95 |
+ * 'anti-aliasing' means that stems are not positioned exactly on pixel
|
|
96 | 96 |
* borders, causing a fuzzy appearance.
|
97 | 97 |
*
|
98 | 98 |
* There are two principles behind this approach.
|
... | ... | @@ -108,7 +108,7 @@ FT_BEGIN_HEADER |
108 | 108 |
* sizes are comparable to kerning values and thus would be noticeable
|
109 | 109 |
* (and distracting) while reading if hinting were applied.
|
110 | 110 |
*
|
111 |
- * One of the reasons to not hint horizontally is antialiasing for LCD
|
|
111 |
+ * One of the reasons to not hint horizontally is anti-aliasing for LCD
|
|
112 | 112 |
* screens: The pixel geometry of modern displays supplies three vertical
|
113 | 113 |
* subpixels as the eye moves horizontally across each visible pixel. On
|
114 | 114 |
* devices where we can be certain this characteristic is present a
|
... | ... | @@ -116,7 +116,7 @@ FT_BEGIN_HEADER |
116 | 116 |
* weight. In Western writing systems this turns out to be the more
|
117 | 117 |
* critical direction anyway; the weights and spacing of vertical stems
|
118 | 118 |
* (see above) are central to Armenian, Cyrillic, Greek, and Latin type
|
119 |
- * designs. Even when the rasterizer uses greyscale antialiasing instead
|
|
119 |
+ * designs. Even when the rasterizer uses greyscale anti-aliasing instead
|
|
120 | 120 |
* of color (a necessary compromise when one doesn't know the screen
|
121 | 121 |
* characteristics), the unhinted vertical features preserve the design's
|
122 | 122 |
* weight and spacing much better than aliased type would.
|
... | ... | @@ -290,7 +290,7 @@ |
290 | 290 |
}
|
291 | 291 |
|
292 | 292 |
/* preset the bitmap using the glyph's outline; */
|
293 |
- /* the sdf bitmap is similar to an antialiased bitmap */
|
|
293 |
+ /* the sdf bitmap is similar to an anti-aliased bitmap */
|
|
294 | 294 |
/* with a slightly bigger size and different pixel mode */
|
295 | 295 |
if ( ft_glyphslot_preset_bitmap( slot, FT_RENDER_MODE_NORMAL, origin ) )
|
296 | 296 |
{
|