Fix typographical errors

Co-authored-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>

Author: THE-Spellchecker

CMakeLists.txt

@@ -87,7 +87,7 @@ endif()
 option(PNG_TESTS "Build the libpng tests" ON)
 
 # Same as above, but for the third-party tools.
-# Although these tools are targetted at development environments only,
+# Although these tools are targeted at development environments only,
 # the users are allowed to override the option to build by default.
 if(ANDROID OR IOS)
   option(PNG_TOOLS "Build the libpng tools" OFF)
@@ -730,7 +730,7 @@ function(create_symlink DEST_FILE)
     message(FATAL_ERROR "create_symlink: Missing arguments: FILE or TARGET")
   endif()
   if(_SYM_FILE AND _SYM_TARGET)
-    message(FATAL_ERROR "create_symlink: Mutually-exlusive arguments:"
+    message(FATAL_ERROR "create_symlink: Mutually-exclusive arguments:"
                         "FILE (${_SYM_FILE}) and TARGET (${_SYM_TARGET})")
   endif()
 

arm/arm_init.c

@@ -99,7 +99,7 @@ png_target_do_expand_palette_neon(png_struct *png_ptr, png_row_info *row_info,
     *    the original code in pngrtran.c  That code is now here.
     *
     * 3) The original code takes pointers to the end of the input and the end of
-    *    the output; this is the way png_do_expand_palette works becuase it
+    *    the output; this is the way png_do_expand_palette works because it
     *    has to copy down from the end (otherwise it would overwrite the input
     *    data before it read it).  Note that the row buffer is aliased by
     *    these two pointers.

contrib/libtests/pngstest.c

@@ -2790,7 +2790,7 @@ compare_two_images(Image *a, Image *b, int via_linear,
     * If an alpha channel has been *added* then it must have the relevant opaque
     * value (255 or 65535).
     *
-    * The fist two the tests (in the order given above) (using the boolean
+    * The first two tests (in the order given above) (using the boolean
     * equivalence !a && !b == !(a || b))
     */
    if (!(((formata ^ formatb) & PNG_FORMAT_FLAG_LINEAR) |

contrib/libtests/pngvalid.c

@@ -6179,7 +6179,7 @@ image_pixel_add_alpha(image_pixel *this, const standard_display *display,
             this->have_tRNS = 0;
 
             /* Check the input, original, channel value here against the
-             * original tRNS gray chunk valie.
+             * original tRNS gray chunk value.
              */
             if (this->red == display->transparent.red)
                this->alphaf = 0;
@@ -7514,7 +7514,7 @@ static struct
    double green_coefficient;
    double blue_coefficient;
 
-   /* Set if the coeefficients have been overridden. */
+   /* Set if the coefficients have been overridden. */
    int coefficients_overridden;
 } data;
 
@@ -8988,7 +8988,7 @@ image_transform_test_counter(png_uint_32 counter, unsigned int max)
       /* For max 0 or 1 continue until the counter overflows: */
       counter >>= 1;
 
-      /* Continue if any entry hasn't reacked the max. */
+      /* Continue if any entry hasn't reached the max. */
       if (max > 1 && next->local_use < max)
          return 1;
       next = next->list;
@@ -9674,7 +9674,7 @@ gamma_component_validate(const char *name, const validate_info *vi,
        *  od: encoded result from libpng
        */
 
-      /* Now we have the numbers for real errors, both absolute values as as a
+      /* Now we have the numbers for real errors, both absolute values as a
        * percentage of the correct value (output):
        */
       error = fabs(input_sample-output);
@@ -11648,7 +11648,7 @@ main(int argc, char **argv)
 #  endif
 
    /* The following allows results to pass if they correspond to anything in the
-    * transformed range [input-.5,input+.5]; this is is required because of the
+    * transformed range [input-.5,input+.5]; this is required because of the
     * way libpng treats the 16_TO_8 flag when building the gamma tables in
     * releases up to 1.6.0.
     *

contrib/pngminus/README.txt

@@ -53,7 +53,7 @@ program are some elementary routines to read / write pgm- and ppm-files.
 It does not handle B&W pbm-files, but instead you could do pgm with bit-
 depth 1.
 
-The downside of this approach is that you can not use them on images
+The downside of this approach is that you cannot use them on images
 that require blocks of memory bigger than 64k (the DOS version). For
 larger images you will get an out-of-memory error.
 

contrib/visupng/VisualPng.c

@@ -832,7 +832,7 @@ BOOL FillBitmap (
         cxNewSize = cxWinSize - 2 * MARGIN;
         cyNewSize = cyWinSize - 2 * MARGIN;
 
-        /* stretch the image to it's window determined size */
+        /* stretch the image to its window determined size */
 
         /* the following two are mathematically the same, but the first
          * has side-effects because of rounding

intel/check.h

@@ -9,7 +9,7 @@
  * For conditions of distribution and use, see the disclaimer
  * and license in png.h
  */
-/* PNG_INTEL_SSE_IMPLEMENTATION is used in the actual implementation to selecct
+/* PNG_INTEL_SSE_IMPLEMENTATION is used in the actual implementation to select
  * the correct code.
  */
 #if defined(__SSE4_1__) || defined(__AVX__)

manuals/libpng-manual.txt

@@ -2312,7 +2312,7 @@ libpng provides two macros to help you in 1.5 and later versions:
    png_uint_32 height = PNG_PASS_ROWS(image_height, pass_number);
 
 Respectively these tell you the width and height of the sub-image
-corresponding to the numbered pass.  'pass' is in in the range 0 to 6 -
+corresponding to the numbered pass.  'pass' is in the range 0 to 6 -
 this can be confusing because the specification refers to the same passes
 as 1 to 7!  Be careful, you must check both the width and height before
 calling png_read_rows() and not call it for that pass if either is zero.
@@ -2451,7 +2451,7 @@ point to libpng-allocated storage with the following function:
 
 This function may be safely called when the relevant storage has
 already been freed, or has not yet been allocated, or was allocated
-by the user and not by libpng,  and will in those cases do nothing.
+by the user and not by libpng, and will in those cases do nothing.
 The "seq" parameter is ignored if only one item of the selected data
 type, such as PLTE, is allowed.  If "seq" is not -1, and multiple items
 are allowed for the data type identified in the mask, such as text or
@@ -3286,7 +3286,7 @@ disclaimer until after, so viewers working over modem connections
 don't have to wait for the disclaimer to go over the modem before
 they start seeing the image.  Finally, keywords should be full
 words, not abbreviations.  Keywords and text are in the ISO 8859-1
-(Latin-1) character set (a superset of regular ASCII) and can not
+(Latin-1) character set (a superset of regular ASCII) and cannot
 contain NUL characters, and should not contain control or other
 unprintable characters.  To make the comments widely readable, stick
 with basic ASCII, and avoid machine specific character set extensions
@@ -3687,7 +3687,7 @@ point to libpng-allocated storage with the following function:
 
 This function may be safely called when the relevant storage has
 already been freed, or has not yet been allocated, or was allocated
-by the user  and not by libpng,  and will in those cases do nothing.
+by the user and not by libpng, and will in those cases do nothing.
 The "seq" parameter is ignored if only one item of the selected data
 type, such as PLTE, is allowed.  If "seq" is not -1, and multiple items
 are allowed for the data type identified in the mask, such as text or

manuals/libpng.3

@@ -2819,7 +2819,7 @@ libpng provides two macros to help you in 1.5 and later versions:
    png_uint_32 height = PNG_PASS_ROWS(image_height, pass_number);
 
 Respectively these tell you the width and height of the sub-image
-corresponding to the numbered pass.  'pass' is in in the range 0 to 6 -
+corresponding to the numbered pass.  'pass' is in the range 0 to 6 -
 this can be confusing because the specification refers to the same passes
 as 1 to 7!  Be careful, you must check both the width and height before
 calling png_read_rows() and not call it for that pass if either is zero.
@@ -2958,7 +2958,7 @@ point to libpng-allocated storage with the following function:
 
 This function may be safely called when the relevant storage has
 already been freed, or has not yet been allocated, or was allocated
-by the user and not by libpng,  and will in those cases do nothing.
+by the user and not by libpng, and will in those cases do nothing.
 The "seq" parameter is ignored if only one item of the selected data
 type, such as PLTE, is allowed.  If "seq" is not \-1, and multiple items
 are allowed for the data type identified in the mask, such as text or
@@ -3793,7 +3793,7 @@ disclaimer until after, so viewers working over modem connections
 don't have to wait for the disclaimer to go over the modem before
 they start seeing the image.  Finally, keywords should be full
 words, not abbreviations.  Keywords and text are in the ISO 8859-1
-(Latin-1) character set (a superset of regular ASCII) and can not
+(Latin-1) character set (a superset of regular ASCII) and cannot
 contain NUL characters, and should not contain control or other
 unprintable characters.  To make the comments widely readable, stick
 with basic ASCII, and avoid machine specific character set extensions
@@ -4194,7 +4194,7 @@ point to libpng-allocated storage with the following function:
 
 This function may be safely called when the relevant storage has
 already been freed, or has not yet been allocated, or was allocated
-by the user  and not by libpng,  and will in those cases do nothing.
+by the user and not by libpng, and will in those cases do nothing.
 The "seq" parameter is ignored if only one item of the selected data
 type, such as PLTE, is allowed.  If "seq" is not \-1, and multiple items
 are allowed for the data type identified in the mask, such as text or

png.c

@@ -1142,7 +1142,7 @@ png_xy_from_XYZ(png_xy *xy, const png_XYZ *XYZ)
       return 1;
 
    /* The reference white is simply the sum of the end-point (X,Y,Z) vectors so
-    * the fillowing calculates (X+Y+Z) of the reference white (media white,
+    * the following calculates (X+Y+Z) of the reference white (media white,
     * encoding white) itself:
     */
    d = dblue;
@@ -1187,9 +1187,9 @@ png_XYZ_from_xy(png_XYZ *XYZ, const png_xy *xy)
     * (-0.0770) because the PNG spec itself requires the xy values to be
     * unsigned.  whitey is also required to be 5 or more to avoid overflow.
     *
-    * Instead the upper limits have been relaxed to accomodate ACES AP1 where
+    * Instead the upper limits have been relaxed to accommodate ACES AP1 where
     * redz ends up as -600 (-0.006).  ProPhotoRGB was already "in range."
-    * The new limit accomodates the AP0 and AP1 ranges for z but not AP0 redy.
+    * The new limit accommodates the AP0 and AP1 ranges for z but not AP0 redy.
     */
    const png_fixed_point fpLimit = PNG_FP_1+(PNG_FP_1/10);
    if (xy->redx   < 0 || xy->redx > fpLimit) return 1;
@@ -1300,7 +1300,7 @@ png_XYZ_from_xy(png_XYZ *XYZ, const png_xy *xy)
     *    red-scale + green-scale + blue-scale = 1/white-y = white-scale
     *
     * So now we have a Cramer's rule solution where the determinants are just
-    * 3x3 - far more tractible.  Unfortunately 3x3 determinants still involve
+    * 3x3 - far more tractable.  Unfortunately 3x3 determinants still involve
     * multiplication of three coefficients so we can't guarantee to avoid
     * overflow in the libpng fixed point representation.  Using Cramer's rule in
     * floating point is probably a good choice here, but it's not an option for
@@ -1669,7 +1669,7 @@ png_icc_check_header(const png_struct *png_ptr, const char *name,
     * into R, G and B channels.
     *
     * Previously it was suggested that an RGB profile on grayscale data could be
-    * handled.  However it it is clear that using an RGB profile in this context
+    * handled.  However it is clear that using an RGB profile in this context
     * must be an error - there is no specification of what it means.  Thus it is
     * almost certainly more correct to ignore the profile.
     */
@@ -2887,7 +2887,7 @@ png_gamma_significant(png_fixed_point gamma_val)
     *
     *    2.2/(2+51/256) == 1.00035524
     *
-    * I.e. vanishly small (<4E-4) but still detectable in 16-bit linear (+/-
+    * I.e. vanishingly small (<4E-4) but still detectable in 16-bit linear (+/-
     * 23).  Note that the Adobe choice seems to be something intended to give an
     * exact number with 8 binary fractional digits - it is the closest to 2.2
     * that is possible a base 2 .8p representation.