[Git][freetype/freetype][master] Update `CHANGES` file; other minor doc fixes.

[Werner Lemberg (@wl)]

Werner Lemberg pushed to branch master at FreeType / FreeType

Commits:

• 90ecac41
  by Werner Lemberg at 2021-06-30T10:23:42+02:00

  Update `CHANGES` file; other minor doc fixes.
  

5 changed files:

• docs/CHANGES
• docs/INSTALL.ANY
• include/freetype/freetype.h
• include/freetype/ftdriver.h
• src/sdf/ftsdfrend.c

Changes:

docs/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	======================================================================

docs/INSTALL.ANY

---

...	...	@@ -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)

include/freetype/freetype.h

---

...	...	@@ -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,

include/freetype/ftdriver.h

---

...	...	@@ -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.

src/sdf/ftsdfrend.c

---

...	...	@@ -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	{

—
View it on GitLab.
You're receiving this email because of your account on gitlab.freedesktop.org. If you'd like to receive fewer emails, you can adjust your notification settings.