Fix docHEAD1.1.2master

Signed-off-by: Mattias Andrée <m@maandree.se>

3 files changed, 15 insertions, 15 deletions

diff --git a/README b/README
index 3ee9fb8..2eecb68 100644
--- a/README
+++ b/README
@@ -2,14 +2,14 @@ NAME
 	libglitter - Subpixel-rendering library
 
 DESCRIPTION
-	libglitter is a C library for subpixel-rendered text from an
+	libglitter is a C library for subpixel-rendered text from a
 	greyscale-antialiased text image. libglitter is designed to be
 	used in conjunction with other font libraries: it can neither
 	rasterise glyphs nor does it know about the monitor's subpixel
 	layout or rendering configurations.
 
 	To use libglitter you first (optionally) apply hinting to the
-	text so that the glyph outlines aligns with the output's
+	text so that the glyph outlines align with the output's
 	pixel-grid as closely as possible. The next step is to get
 	the output's subpixel arrangement and scaling factor, then
 	assuming that the output's subpixel arrangement is subpixel-
diff --git a/libglitter.7 b/libglitter.7
index 8144ea7..3804013 100644
--- a/libglitter.7
+++ b/libglitter.7
@@ -3,7 +3,7 @@
 libglitter - Subpixel-rendering library
 .SH DESCRIPTION
 .B libglitter
-is a C library for subpixel-rendered text from an
+is a C library for subpixel-rendered text from a
 greyscale-antialiased text image.
 .B libglitter
 is designed to be
@@ -14,7 +14,7 @@ layout or rendering configurations.
 To use
 .B libglitter
 you first (optionally) apply hinting to the text so that
-the glyph outlines aligns with the output's pixel-grid as
+the glyph outlines align with the output's pixel-grid as
 closely as possible. The next step is to get the output's
 subpixel arrangement and scaling factor, then assuming that
 the output's subpixel arrangement is subpixel-rendering
@@ -94,7 +94,7 @@ desirable for all applications.
 Some users are more sensitive to colour while other users
 are more sensitive to shape. Subpixel-antialiasing, if done
 well, is a good option for users that are more sensitive
-to shape. However, for users that are more sensative to
+to shape. However, for users that are more sensitive to
 colour, subpixel-antialiasing renders glittering, and reading
 subpixel-antialiased text can be headache inducing, especially
 if implemented poorly or if the monitor doesn't have high
@@ -102,7 +102,7 @@ enough pixel density (for some users just above normal laptop
 pixel density can be fine, but for others, not even 4K on a
 laptop is good enough). For these users, greyscale-antialiasing
 is a much better option. For this reason, applications must
-not for subpixel-antialiasing, and should even only used it
+not default to subpixel-antialiasing, and should only use it
 if the user explicitly requests it.
 .PP
 Hinting is another important issue. For aliased text, hinting
@@ -121,10 +121,10 @@ hinting removes fringing (colours along the edge of a stroke)
 and miscoloured strokes, strokes can even disappear: for
 example, if the stroke only hits blue subpixels, but should be
 rendered as pure red (the primary colour) on black, there will
-only be black, as that is what primary red muliplied by primary
-blue results in. Applications are discourage for using
-subpixel-rendering on non-hinted text unless that user
-explicitly says it he wants subpixel-rendered text even it will
+only be black, as that is what primary red multiplied by primary
+blue results in. Applications are discouraged from using
+subpixel-rendering on non-hinted text unless the user explicitly
+says that he want subpixel-rendered text even if it will
 look bad (presumably to see how it looks). Subpixel-rendering
 may also be a bad idea on coloured text.
 .PP
diff --git a/libglitter.h b/libglitter.h
index fe83073..940088f 100644
--- a/libglitter.h
+++ b/libglitter.h
@@ -148,7 +148,7 @@ enum libglitter_colour {
  *                    - LIBGLITTER_FEATURE_UINT32_TYPE,
  *                    - LIBGLITTER_FEATURE_UINT16_TYPE,
  *                    - LIBGLITTER_FEATURE_UINT8_TYPE,
- '                    - LIBGLITTER_FEATURE_REDISTRIBUTE,
+ *                    - LIBGLITTER_FEATURE_REDISTRIBUTE,
  *                    - LIBGLITTER_FEATURE_COMPOSE,
  *                    - LIBGLITTER_FEATURE_CU_DESATURATION,
  *                    - LIBGLITTER_FEATURE_PC_DESATURATION, and
@@ -200,10 +200,10 @@ void libglitter_free_render_context(LIBGLITTER_RENDER_CONTEXT *);
  *                      `libglitter_free_render_context` or updated with
  *                      `libglitter_update_render_context`; `NULL` on failure
  *
- * @throws  ENOMEM  Couldn't not allocate enough memory
+ * @throws  ENOMEM  Could not allocate enough memory
  * 
  * If `noutputs` is 3 and either `widthmul` or `heightmul` is 3 and
- * the other one is 1, `ncellvalues` will not be used as it is preknown
+ * the other one is 1, `ncellvalues` will not be used as it is known
  * that all its values are 1; in the future this could also happen for
  * other situations where `noutputs == widthmul * heightmul`
  * 
@@ -250,12 +250,12 @@ void libglitter_update_render_context(LIBGLITTER_RENDER_CONTEXT *, size_t);
  * `libglitter_create_render_context` function); so that
  * the raster can be input to `libglitter_compose_double`.
  * 
- * @param  raster          The subpixel raster. The must be padded with
+ * @param  raster          The subpixel raster. It must be padded with
  *                         zero-initialised cells on the left side and
  *                         on the top. This padding must `(hkernelsize - 1)`
  *                         cells wide the left side and `(vkernelsize - 1)`
  *                         cells tall on the top. The new image will be
- *                         written to this raster must shiften upwards
+ *                         written to this raster must be shifted upwards
  *                         `(vkernelsize - 1) / 2` cells and to the left
  *                         `(hkernelsize - 1) / 2` cells. The image will
  *                         also be extended by `(hkernelsize - 1) / 2`