Commit 90ecac4118eb18b2f9e2f72cc0e0fdd42144bfe3

Werner Lemberg 2021-06-30T10:23:42

Update `CHANGES` file; other minor doc fixes.

diff --git a/docs/CHANGES b/docs/CHANGES
index 95f0e39..2151c84 100644
--- a/docs/CHANGES
+++ b/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.
 
 
 ======================================================================
diff --git a/docs/INSTALL.ANY b/docs/INSTALL.ANY
index e1c4a46..f36c2e0 100644
--- a/docs/INSTALL.ANY
+++ b/docs/INSTALL.ANY
@@ -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)
diff --git a/include/freetype/freetype.h b/include/freetype/freetype.h
index da93e81..29a0f71 100644
--- a/include/freetype/freetype.h
+++ b/include/freetype/freetype.h
@@ -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,
diff --git a/include/freetype/ftdriver.h b/include/freetype/ftdriver.h
index fc4276c..59ae843 100644
--- a/include/freetype/ftdriver.h
+++ b/include/freetype/ftdriver.h
@@ -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.
diff --git a/src/sdf/ftsdfrend.c b/src/sdf/ftsdfrend.c
index 8df333a..420ad49 100644
--- a/src/sdf/ftsdfrend.c
+++ b/src/sdf/ftsdfrend.c
@@ -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 ) )
     {