+png_set_error_fn(), which is essentially the same function, but with a new
+name to force compilation errors with applications that try to use the old
+method.
+
+Starting with version 1.0.7, you can find out which version of the library
+you are using at run-time:
+
+ png_uint_32 libpng_vn = png_access_version_number();
+
+The number libpng_vn is constructed from the major version, minor
+version with leading zero, and release number with leading zero,
+(e.g., libpng_vn for version 1.0.7 is 10007).
+
+Note that this function does not take a png_ptr, so you can call it
+before you've created one.
+
+You can also check which version of png.h you used when compiling your
+application:
+
+ png_uint_32 application_vn = PNG_LIBPNG_VER;
+
+.SH IX. Changes to Libpng from version 1.0.x to 1.2.x
+
+Support for user memory management was enabled by default. To
+accomplish this, the functions png_create_read_struct_2(),
+png_create_write_struct_2(), png_set_mem_fn(), png_get_mem_ptr(),
+png_malloc_default(), and png_free_default() were added.
+
+Support for the iTXt chunk has been enabled by default as of
+version 1.2.41.
+
+Support for certain MNG features was enabled.
+
+Support for numbered error messages was added. However, we never got
+around to actually numbering the error messages. The function
+png_set_strip_error_numbers() was added (Note: the prototype for this
+function was inadvertently removed from png.h in PNG_NO_ASSEMBLER_CODE
+builds of libpng-1.2.15. It was restored in libpng-1.2.36).
+
+The png_malloc_warn() function was added at libpng-1.2.3. This issues
+a png_warning and returns NULL instead of aborting when it fails to
+acquire the requested memory allocation.
+
+Support for setting user limits on image width and height was enabled
+by default. The functions png_set_user_limits(), png_get_user_width_max(),
+and png_get_user_height_max() were added at libpng-1.2.6.
+
+The png_set_add_alpha() function was added at libpng-1.2.7.
+
+The function png_set_expand_gray_1_2_4_to_8() was added at libpng-1.2.9.
+Unlike png_set_gray_1_2_4_to_8(), the new function does not expand the
+tRNS chunk to alpha. The png_set_gray_1_2_4_to_8() function is
+deprecated.
+
+A number of macro definitions in support of runtime selection of
+assembler code features (especially Intel MMX code support) were
+added at libpng-1.2.0:
+
+ PNG_ASM_FLAG_MMX_SUPPORT_COMPILED
+ PNG_ASM_FLAG_MMX_SUPPORT_IN_CPU
+ PNG_ASM_FLAG_MMX_READ_COMBINE_ROW
+ PNG_ASM_FLAG_MMX_READ_INTERLACE
+ PNG_ASM_FLAG_MMX_READ_FILTER_SUB
+ PNG_ASM_FLAG_MMX_READ_FILTER_UP
+ PNG_ASM_FLAG_MMX_READ_FILTER_AVG
+ PNG_ASM_FLAG_MMX_READ_FILTER_PAETH
+ PNG_ASM_FLAGS_INITIALIZED
+ PNG_MMX_READ_FLAGS
+ PNG_MMX_FLAGS
+ PNG_MMX_WRITE_FLAGS
+ PNG_MMX_FLAGS
+
+We added the following functions in support of runtime
+selection of assembler code features:
+
+ png_get_mmx_flagmask()
+ png_set_mmx_thresholds()
+ png_get_asm_flags()
+ png_get_mmx_bitdepth_threshold()
+ png_get_mmx_rowbytes_threshold()
+ png_set_asm_flags()
+
+We replaced all of these functions with simple stubs in libpng-1.2.20,
+when the Intel assembler code was removed due to a licensing issue.
+
+These macros are deprecated:
+
+ PNG_READ_TRANSFORMS_NOT_SUPPORTED
+ PNG_PROGRESSIVE_READ_NOT_SUPPORTED
+ PNG_NO_SEQUENTIAL_READ_SUPPORTED
+ PNG_WRITE_TRANSFORMS_NOT_SUPPORTED
+ PNG_READ_ANCILLARY_CHUNKS_NOT_SUPPORTED
+ PNG_WRITE_ANCILLARY_CHUNKS_NOT_SUPPORTED
+
+They have been replaced, respectively, by:
+
+ PNG_NO_READ_TRANSFORMS
+ PNG_NO_PROGRESSIVE_READ
+ PNG_NO_SEQUENTIAL_READ
+ PNG_NO_WRITE_TRANSFORMS
+ PNG_NO_READ_ANCILLARY_CHUNKS
+ PNG_NO_WRITE_ANCILLARY_CHUNKS
+
+PNG_MAX_UINT was replaced with PNG_UINT_31_MAX. It has been
+deprecated since libpng-1.0.16 and libpng-1.2.6.
+
+The function
+ png_check_sig(sig, num)
+was replaced with
+ !png_sig_cmp(sig, 0, num)
+It has been deprecated since libpng-0.90.
+
+The function
+ png_set_gray_1_2_4_to_8()
+which also expands tRNS to alpha was replaced with
+ png_set_expand_gray_1_2_4_to_8()
+which does not. It has been deprecated since libpng-1.0.18 and 1.2.9.
+
+.SH X. Changes to Libpng from version 1.0.x/1.2.x to 1.4.x
+
+Private libpng prototypes and macro definitions were moved from
+png.h and pngconf.h into a new pngpriv.h header file.
+
+Functions png_set_benign_errors(), png_benign_error(), and
+png_chunk_benign_error() were added.
+
+Support for setting the maximum amount of memory that the application
+will allocate for reading chunks was added, as a security measure.
+The functions png_set_chunk_cache_max() and png_get_chunk_cache_max()
+were added to the library.
+
+We implemented support for I/O states by adding png_ptr member io_state
+and functions png_get_io_chunk_name() and png_get_io_state() in pngget.c
+
+We added PNG_TRANSFORM_GRAY_TO_RGB to the available high-level
+input transforms.
+
+Checking for and reporting of errors in the IHDR chunk is more thorough.
+
+Support for global arrays was removed, to improve thread safety.
+
+Some obsolete/deprecated macros and functions have been removed.
+
+Typecasted NULL definitions such as
+ #define png_voidp_NULL (png_voidp)NULL
+were eliminated. If you used these in your application, just use
+NULL instead.
+
+The png_struct and info_struct members "trans" and "trans_values" were
+changed to "trans_alpha" and "trans_color", respectively.
+
+The obsolete, unused pnggccrd.c and pngvcrd.c files and related makefiles
+were removed.
+
+The PNG_1_0_X and PNG_1_2_X macros were eliminated.
+
+The PNG_LEGACY_SUPPORTED macro was eliminated.
+
+Many WIN32_WCE #ifdefs were removed.
+
+The functions png_read_init(info_ptr), png_write_init(info_ptr),
+png_info_init(info_ptr), png_read_destroy(), and png_write_destroy()
+have been removed. They have been deprecated since libpng-0.95.
+
+The png_permit_empty_plte() was removed. It has been deprecated
+since libpng-1.0.9. Use png_permit_mng_features() instead.
+
+We removed the obsolete stub functions png_get_mmx_flagmask(),
+png_set_mmx_thresholds(), png_get_asm_flags(),
+png_get_mmx_bitdepth_threshold(), png_get_mmx_rowbytes_threshold(),
+png_set_asm_flags(), and png_mmx_supported()
+
+We removed the obsolete png_check_sig(), png_memcpy_check(), and
+png_memset_check() functions. Instead use !png_sig_cmp(), memcpy(),
+and memset(), respectively.
+
+The function png_set_gray_1_2_4_to_8() was removed. It has been
+deprecated since libpng-1.0.18 and 1.2.9, when it was replaced with
+png_set_expand_gray_1_2_4_to_8() because the former function also
+expanded any tRNS chunk to an alpha channel.
+
+Macros for png_get_uint_16, png_get_uint_32, and png_get_int_32
+were added and are used by default instead of the corresponding
+functions. Unfortunately,
+from libpng-1.4.0 until 1.4.4, the png_get_uint_16 macro (but not the
+function) incorrectly returned a value of type png_uint_32.
+
+We changed the prototype for png_malloc() from
+ png_malloc(png_structp png_ptr, png_uint_32 size)
+to
+ png_malloc(png_structp png_ptr, png_alloc_size_t size)
+
+This also applies to the prototype for the user replacement malloc_fn().
+
+The png_calloc() function was added and is used in place of
+of "png_malloc(); memset();" except in the case in png_read_png()
+where the array consists of pointers; in this case a "for" loop is used
+after the png_malloc() to set the pointers to NULL, to give robust.
+behavior in case the application runs out of memory part-way through
+the process.
+
+We changed the prototypes of png_get_compression_buffer_size() and
+png_set_compression_buffer_size() to work with png_size_t instead of
+png_uint_32.
+
+Support for numbered error messages was removed by default, since we
+never got around to actually numbering the error messages. The function
+png_set_strip_error_numbers() was removed from the library by default.
+
+The png_zalloc() and png_zfree() functions are no longer exported.
+The png_zalloc() function no longer zeroes out the memory that it
+allocates. Applications that called png_zalloc(png_ptr, number, size)
+can call png_calloc(png_ptr, number*size) instead, and can call
+png_free() instead of png_zfree().
+
+Support for dithering was disabled by default in libpng-1.4.0, because
+it has not been well tested and doesn't actually "dither".
+The code was not
+removed, however, and could be enabled by building libpng with
+PNG_READ_DITHER_SUPPORTED defined. In libpng-1.4.2, this support
+was reenabled, but the function was renamed png_set_quantize() to
+reflect more accurately what it actually does. At the same time,
+the PNG_DITHER_[RED,GREEN_BLUE]_BITS macros were also renamed to
+PNG_QUANTIZE_[RED,GREEN,BLUE]_BITS, and PNG_READ_DITHER_SUPPORTED
+was renamed to PNG_READ_QUANTIZE_SUPPORTED.
+
+We removed the trailing '.' from the warning and error messages.
+
+.SH XI. Changes to Libpng from version 1.4.x to 1.5.x
+
+From libpng-1.4.0 until 1.4.4, the png_get_uint_16 macro (but not the
+function) incorrectly returned a value of type png_uint_32.
+
+Checking for invalid palette index on read or write was added at libpng
+1.5.10. When an invalid index is found, libpng issues a benign error.
+This is enabled by default because this condition is an error according
+to the PNG specification, Clause 11.3.2, but the error can be ignored in
+each png_ptr with
+
+ png_set_check_for_invalid_index(png_ptr, allowed);
+
+ allowed - one of
+ 0: disable benign error (accept the
+ invalid data without warning).
+ 1: enable benign error (treat the
+ invalid data as an error or a
+ warning).
+
+If the error is ignored, or if png_benign_error() treats it as a warning,
+any invalid pixels are decoded as opaque black by the decoder and written
+as-is by the encoder.
+
+Retrieving the maximum palette index found was added at libpng-1.5.15.
+This statement must appear after png_read_png() or png_read_image() while
+reading, and after png_write_png() or png_write_image() while writing.
+
+ int max_palette = png_get_palette_max(png_ptr, info_ptr);
+
+This will return the maximum palette index found in the image, or "-1" if
+the palette was not checked, or "0" if no palette was found. Note that this
+does not account for any palette index used by ancillary chunks such as the
+bKGD chunk; you must check those separately to determine the maximum
+palette index actually used.
+
+A. Changes that affect users of libpng
+
+There are no substantial API changes between the non-deprecated parts of
+the 1.4.5 API and the 1.5.0 API; however, the ability to directly access
+members of the main libpng control structures, png_struct and png_info,
+deprecated in earlier versions of libpng, has been completely removed from
+libpng 1.5.
+
+We no longer include zlib.h in png.h. The include statement has been moved
+to pngstruct.h, where it is not accessible by applications. Applications that
+need access to information in zlib.h will need to add the '#include "zlib.h"'
+directive. It does not matter whether this is placed prior to or after
+the '"#include png.h"' directive.
+
+The png_sprintf(), png_strcpy(), and png_strncpy() macros are no longer used
+and were removed.
+
+We moved the png_strlen(), png_memcpy(), png_memset(), and png_memcmp()
+macros into a private header file (pngpriv.h) that is not accessible to
+applications.
+
+In png_get_iCCP, the type of "profile" was changed from png_charpp
+to png_bytepp, and in png_set_iCCP, from png_charp to png_const_bytep.
+
+There are changes of form in png.h, including new and changed macros to
+declare parts of the API. Some API functions with arguments that are
+pointers to data not modified within the function have been corrected to
+declare these arguments with PNG_CONST.
+
+Much of the internal use of C macros to control the library build has also
+changed and some of this is visible in the exported header files, in
+particular the use of macros to control data and API elements visible
+during application compilation may require significant revision to
+application code. (It is extremely rare for an application to do this.)
+
+Any program that compiled against libpng 1.4 and did not use deprecated
+features or access internal library structures should compile and work
+against libpng 1.5, except for the change in the prototype for
+png_get_iCCP() and png_set_iCCP() API functions mentioned above.
+
+libpng 1.5.0 adds PNG_ PASS macros to help in the reading and writing of
+interlaced images. The macros return the number of rows and columns in
+each pass and information that can be used to de-interlace and (if
+absolutely necessary) interlace an image.
+
+libpng 1.5.0 adds an API png_longjmp(png_ptr, value). This API calls
+the application-provided png_longjmp_ptr on the internal, but application
+initialized, longjmp buffer. It is provided as a convenience to avoid
+the need to use the png_jmpbuf macro, which had the unnecessary side
+effect of resetting the internal png_longjmp_ptr value.
+
+libpng 1.5.0 includes a complete fixed point API. By default this is
+present along with the corresponding floating point API. In general the
+fixed point API is faster and smaller than the floating point one because
+the PNG file format used fixed point, not floating point. This applies
+even if the library uses floating point in internal calculations. A new
+macro, PNG_FLOATING_ARITHMETIC_SUPPORTED, reveals whether the library
+uses floating point arithmetic (the default) or fixed point arithmetic
+internally for performance critical calculations such as gamma correction.
+In some cases, the gamma calculations may produce slightly different
+results. This has changed the results in png_rgb_to_gray and in alpha
+composition (png_set_background for example). This applies even if the
+original image was already linear (gamma == 1.0) and, therefore, it is
+not necessary to linearize the image. This is because libpng has *not*
+been changed to optimize that case correctly, yet.
+
+Fixed point support for the sCAL chunk comes with an important caveat;
+the sCAL specification uses a decimal encoding of floating point values
+and the accuracy of PNG fixed point values is insufficient for
+representation of these values. Consequently a "string" API
+(png_get_sCAL_s and png_set_sCAL_s) is the only reliable way of reading
+arbitrary sCAL chunks in the absence of either the floating point API or
+internal floating point calculations.
+
+Applications no longer need to include the optional distribution header
+file pngusr.h or define the corresponding macros during application
+build in order to see the correct variant of the libpng API. From 1.5.0
+application code can check for the corresponding _SUPPORTED macro:
+
+#ifdef PNG_INCH_CONVERSIONS_SUPPORTED
+ /* code that uses the inch conversion APIs. */
+#endif
+
+This macro will only be defined if the inch conversion functions have been
+compiled into libpng. The full set of macros, and whether or not support
+has been compiled in, are available in the header file pnglibconf.h.
+This header file is specific to the libpng build. Notice that prior to
+1.5.0 the _SUPPORTED macros would always have the default definition unless
+reset by pngusr.h or by explicit settings on the compiler command line.
+These settings may produce compiler warnings or errors in 1.5.0 because
+of macro redefinition.
+
+From libpng-1.4.0 until 1.4.4, the png_get_uint_16 macro (but not the
+function) incorrectly returned a value of type png_uint_32. libpng 1.5.0
+is consistent with the implementation in 1.4.5 and 1.2.x (where the macro
+did not exist.)
+
+Applications can now choose whether to use these macros or to call the
+corresponding function by defining PNG_USE_READ_MACROS or
+PNG_NO_USE_READ_MACROS before including png.h. Notice that this is
+only supported from 1.5.0 -defining PNG_NO_USE_READ_MACROS prior to 1.5.0
+will lead to a link failure.
+
+Prior to libpng-1.5.4, the zlib compressor used the same set of parameters
+when compressing the IDAT data and textual data such as zTXt and iCCP.
+In libpng-1.5.4 we reinitialized the zlib stream for each type of data.
+We added five png_set_text_*() functions for setting the parameters to
+use with textual data.
+
+Prior to libpng-1.5.4, the PNG_READ_16_TO_8_ACCURATE_SCALE_SUPPORTED
+option was off by default, and slightly inaccurate scaling occurred.
+This option can no longer be turned off, and the choice of accurate
+or inaccurate 16-to-8 scaling is by using the new png_set_scale_16_to_8()
+API for accurate scaling or the old png_set_strip_16_to_8() API for simple
+chopping.
+
+Prior to libpng-1.5.4, the png_set_user_limits() function could only be
+used to reduce the width and height limits from the value of
+PNG_USER_WIDTH_MAX and PNG_USER_HEIGHT_MAX, although this document said
+that it could be used to override them. Now this function will reduce or
+increase the limits.
+
+Starting in libpng-1.5.10, the user limits can be set en masse with the
+configuration option PNG_SAFE_LIMITS_SUPPORTED. If this option is enabled,
+a set of "safe" limits is applied in pngpriv.h. These can be overridden by
+application calls to png_set_user_limits(), png_set_user_chunk_cache_max(),
+and/or png_set_user_malloc_max() that increase or decrease the limits. Also,
+in libpng-1.5.10 the default width and height limits were increased
+from 1,000,000 to 0x7ffffff (i.e., made unlimited). Therefore, the
+limits are now
+ default safe
+ png_user_width_max 0x7fffffff 1,000,000
+ png_user_height_max 0x7fffffff 1,000,000
+ png_user_chunk_cache_max 0 (unlimited) 128
+ png_user_chunk_malloc_max 0 (unlimited) 8,000,000
+
+B. Changes to the build and configuration of libpng
+
+Details of internal changes to the library code can be found in the CHANGES
+file and in the GIT repository logs. These will be of no concern to the vast
+majority of library users or builders; however, the few who configure libpng
+to a non-default feature set may need to change how this is done.
+
+There should be no need for library builders to alter build scripts if
+these use the distributed build support - configure or the makefiles -
+however, users of the makefiles may care to update their build scripts
+to build pnglibconf.h where the corresponding makefile does not do so.
+
+Building libpng with a non-default configuration has changed completely.
+The old method using pngusr.h should still work correctly even though the
+way pngusr.h is used in the build has been changed; however, library
+builders will probably want to examine the changes to take advantage of
+new capabilities and to simplify their build system.
+
+B.1 Specific changes to library configuration capabilities
+
+The library now supports a complete fixed point implementation and can
+thus be used on systems that have no floating point support or very
+limited or slow support. Previously gamma correction, an essential part
+of complete PNG support, required reasonably fast floating point.
+
+As part of this the choice of internal implementation has been made
+independent of the choice of fixed versus floating point APIs and all the
+missing fixed point APIs have been implemented.
+
+The exact mechanism used to control attributes of API functions has
+changed. A single set of operating system independent macro definitions
+is used and operating system specific directives are defined in
+pnglibconf.h
+
+As part of this the mechanism used to choose procedure call standards on
+those systems that allow a choice has been changed. At present this only
+affects certain Microsoft (DOS, Windows) and IBM (OS/2) operating systems
+running on Intel processors. As before, PNGAPI is defined where required
+to control the exported API functions; however, two new macros, PNGCBAPI
+and PNGCAPI, are used instead for callback functions (PNGCBAPI) and
+(PNGCAPI) for functions that must match a C library prototype (currently
+only png_longjmp_ptr, which must match the C longjmp function.) The new
+approach is documented in pngconf.h
+
+Despite these changes, libpng 1.5.0 only supports the native C function
+calling standard on those platforms tested so far (__cdecl on Microsoft
+Windows). This is because the support requirements for alternative
+calling conventions seem to no longer exist. Developers who find it
+necessary to set PNG_API_RULE to 1 should advise the mailing list
+(png-mng-implement) of this and library builders who use Openwatcom and
+therefore set PNG_API_RULE to 2 should also contact the mailing list.
+
+A new test program, pngvalid, is provided in addition to pngtest.
+pngvalid validates the arithmetic accuracy of the gamma correction
+calculations and includes a number of validations of the file format.
+A subset of the full range of tests is run when "make check" is done
+(in the 'configure' build.) pngvalid also allows total allocated memory
+usage to be evaluated and performs additional memory overwrite validation.
+
+Many changes to individual feature macros have been made. The following
+are the changes most likely to be noticed by library builders who
+configure libpng:
+
+1) All feature macros now have consistent naming:
+
+#define PNG_NO_feature turns the feature off
+#define PNG_feature_SUPPORTED turns the feature on
+
+pnglibconf.h contains one line for each feature macro which is either:
+
+#define PNG_feature_SUPPORTED
+
+if the feature is supported or:
+
+/*#undef PNG_feature_SUPPORTED*/
+
+if it is not. Library code consistently checks for the 'SUPPORTED' macro.
+It does not, and libpng applications should not, check for the 'NO' macro
+which will not normally be defined even if the feature is not supported.
+The 'NO' macros are only used internally for setting or not setting the
+corresponding 'SUPPORTED' macros.
+
+Compatibility with the old names is provided as follows:
+
+PNG_INCH_CONVERSIONS turns on PNG_INCH_CONVERSIONS_SUPPORTED
+
+And the following definitions disable the corresponding feature:
+
+PNG_SETJMP_NOT_SUPPORTED disables SETJMP
+PNG_READ_TRANSFORMS_NOT_SUPPORTED disables READ_TRANSFORMS
+PNG_NO_READ_COMPOSITED_NODIV disables READ_COMPOSITE_NODIV
+PNG_WRITE_TRANSFORMS_NOT_SUPPORTED disables WRITE_TRANSFORMS
+PNG_READ_ANCILLARY_CHUNKS_NOT_SUPPORTED disables READ_ANCILLARY_CHUNKS
+PNG_WRITE_ANCILLARY_CHUNKS_NOT_SUPPORTED disables WRITE_ANCILLARY_CHUNKS
+
+Library builders should remove use of the above, inconsistent, names.
+
+2) Warning and error message formatting was previously conditional on
+the STDIO feature. The library has been changed to use the
+CONSOLE_IO feature instead. This means that if CONSOLE_IO is disabled
+the library no longer uses the printf(3) functions, even though the
+default read/write implementations use (FILE) style stdio.h functions.
+
+3) Three feature macros now control the fixed/floating point decisions:
+
+PNG_FLOATING_POINT_SUPPORTED enables the floating point APIs
+
+PNG_FIXED_POINT_SUPPORTED enables the fixed point APIs; however, in
+practice these are normally required internally anyway (because the PNG
+file format is fixed point), therefore in most cases PNG_NO_FIXED_POINT
+merely stops the function from being exported.
+
+PNG_FLOATING_ARITHMETIC_SUPPORTED chooses between the internal floating
+point implementation or the fixed point one. Typically the fixed point
+implementation is larger and slower than the floating point implementation
+on a system that supports floating point; however, it may be faster on a
+system which lacks floating point hardware and therefore uses a software
+emulation.
+
+4) Added PNG_{READ,WRITE}_INT_FUNCTIONS_SUPPORTED. This allows the
+functions to read and write ints to be disabled independently of
+PNG_USE_READ_MACROS, which allows libpng to be built with the functions
+even though the default is to use the macros - this allows applications
+to choose at app buildtime whether or not to use macros (previously
+impossible because the functions weren't in the default build.)
+
+B.2 Changes to the configuration mechanism
+
+Prior to libpng-1.5.0 library builders who needed to configure libpng
+had either to modify the exported pngconf.h header file to add system
+specific configuration or had to write feature selection macros into
+pngusr.h and cause this to be included into pngconf.h by defining
+PNG_USER_CONFIG. The latter mechanism had the disadvantage that an
+application built without PNG_USER_CONFIG defined would see the
+unmodified, default, libpng API and thus would probably fail to link.
+
+These mechanisms still work in the configure build and in any makefile
+build that builds pnglibconf.h, although the feature selection macros
+have changed somewhat as described above. In 1.5.0, however, pngusr.h is
+processed only once, when the exported header file pnglibconf.h is built.
+pngconf.h no longer includes pngusr.h, therefore pngusr.h is ignored after the
+build of pnglibconf.h and it is never included in an application build.
+
+The rarely used alternative of adding a list of feature macros to the
+CFLAGS setting in the build also still works; however, the macros will be
+copied to pnglibconf.h and this may produce macro redefinition warnings
+when the individual C files are compiled.
+
+All configuration now only works if pnglibconf.h is built from
+scripts/pnglibconf.dfa. This requires the program awk. Brian Kernighan
+(the original author of awk) maintains C source code of that awk and this
+and all known later implementations (often called by subtly different
+names - nawk and gawk for example) are adequate to build pnglibconf.h.
+The Sun Microsystems (now Oracle) program 'awk' is an earlier version
+and does not work; this may also apply to other systems that have a
+functioning awk called 'nawk'.
+
+Configuration options are now documented in scripts/pnglibconf.dfa. This
+file also includes dependency information that ensures a configuration is
+consistent; that is, if a feature is switched off dependent features are
+also removed. As a recommended alternative to using feature macros in
+pngusr.h a system builder may also define equivalent options in pngusr.dfa
+(or, indeed, any file) and add that to the configuration by setting
+DFA_XTRA to the file name. The makefiles in contrib/pngminim illustrate
+how to do this, and a case where pngusr.h is still required.
+
+.SH XII. Changes to Libpng from version 1.5.x to 1.6.x
+
+A "simplified API" has been added (see documentation in png.h and a simple
+example in contrib/examples/pngtopng.c). The new publicly visible API
+includes the following:
+
+ macros:
+ PNG_FORMAT_*
+ PNG_IMAGE_*
+ structures:
+ png_control
+ png_image
+ read functions
+ png_image_begin_read_from_file()
+ png_image_begin_read_from_stdio()
+ png_image_begin_read_from_memory()
+ png_image_finish_read()
+ png_image_free()
+ write functions
+ png_image_write_to_file()
+ png_image_write_to_stdio()
+
+Starting with libpng-1.6.0, you can configure libpng to prefix all exported
+symbols, using the PNG_PREFIX macro.
+
+We no longer include string.h in png.h. The include statement has been moved
+to pngpriv.h, where it is not accessible by applications. Applications that
+need access to information in string.h must add an '#include "string.h"'
+directive. It does not matter whether this is placed prior to or after
+the '"#include png.h"' directive.
+
+The following API are now DEPRECATED:
+ png_info_init_3()
+ png_convert_to_rfc1123() which has been replaced
+ with png_convert_to_rfc1123_buffer()
+ png_data_freer()
+ png_malloc_default()
+ png_free_default()
+ png_reset_zstream()
+
+The following have been removed:
+ png_get_io_chunk_name(), which has been replaced
+ with png_get_io_chunk_type(). The new
+ function returns a 32-bit integer instead of
+ a string.
+ The png_sizeof(), png_strlen(), png_memcpy(), png_memcmp(), and
+ png_memset() macros are no longer used in the libpng sources and
+ have been removed. These had already been made invisible to applications
+ (i.e., defined in the private pngpriv.h header file) since libpng-1.5.0.
+
+The signatures of many exported functions were changed, such that
+ png_structp became png_structrp or png_const_structrp
+ png_infop became png_inforp or png_const_inforp
+where "rp" indicates a "restricted pointer".
+
+Error detection in some chunks has improved; in particular the iCCP chunk
+reader now does pretty complete validation of the basic format. Some bad
+profiles that were previously accepted are now rejected, in particular the
+very old broken Microsoft/HP sRGB profile. The PNG spec requirement that
+only grayscale profiles may appear in images with color type 0 or 4 and that
+even if the image only contains gray pixels, only RGB profiles may appear
+in images with color type 2, 3, or 6, is now enforced. The sRGB chunk
+is allowed to appear in images with any color type.
+
+The library now issues an error if the application attempts to set a
+transform after it calls png_read_update_info().
+
+The library now issues a warning if both background processing and RGB to
+gray are used when gamma correction happens. As with previous versions of
+the library the results are numerically very incorrect in this case.
+
+There are some minor arithmetic changes in some transforms such as
+png_set_background(), that might be detected by certain regression tests.
+
+Unknown chunk handling has been improved internally, without any API change.
+This adds more correct option control of the unknown handling, corrects
+a pre-existing bug where the per-chunk 'keep' setting is ignored, and makes
+it possible to skip IDAT chunks in the sequential reader.
+
+The machine-generated configure files are no longer included in branches
+libpng16 and later of the GIT repository. They continue to be included
+in the tarball releases, however.
+
+.SH XIII. Detecting libpng
+
+The png_get_io_ptr() function has been present since libpng-0.88, has never
+changed, and is unaffected by conditional compilation macros. It is the
+best choice for use in configure scripts for detecting the presence of any
+libpng version since 0.88. In an autoconf "configure.in" you could use
+
+ AC_CHECK_LIB(png, png_get_io_ptr, ...
+
+.SH XV. Source code repository
+
+Since about February 2009, version 1.2.34, libpng has been under "git" source
+control. The git repository was built from old libpng-x.y.z.tar.gz files
+going back to version 0.70. You can access the git repository (read only)
+at
+
+ git://git.code.sf.net/p/libpng/code
+
+or you can browse it with a web browser by selecting the "code" button at
+
+ https://sourceforge.net/projects/libpng
+
+Patches can be sent to glennrp at users.sourceforge.net or to
+png-mng-implement at lists.sourceforge.net or you can upload them to
+the libpng bug tracker at
+
+ http://libpng.sourceforge.net
+
+We also accept patches built from the tar or zip distributions, and
+simple verbal discriptions of bug fixes, reported either to the
+SourceForge bug tracker, to the png-mng-implement at lists.sf.net
+mailing list, or directly to glennrp.
+
+.SH XV. Coding style
+
+Our coding style is similar to the "Allman" style, with curly
+braces on separate lines:
+
+ if (condition)
+ {
+ action;
+ }
+
+ else if (another condition)
+ {
+ another action;
+ }
+
+The braces can be omitted from simple one-line actions:
+
+ if (condition)
+ return (0);
+
+We use 3-space indentation, except for continued statements which
+are usually indented the same as the first line of the statement
+plus four more spaces.
+
+For macro definitions we use 2-space indentation, always leaving the "#"
+in the first column.
+
+ #ifndef PNG_NO_FEATURE
+ # ifndef PNG_FEATURE_SUPPORTED
+ # define PNG_FEATURE_SUPPORTED
+ # endif
+ #endif
+
+Comments appear with the leading "/*" at the same indentation as
+the statement that follows the comment:
+
+ /* Single-line comment */
+ statement;
+
+ /* This is a multiple-line
+ * comment.
+ */
+ statement;
+
+Very short comments can be placed after the end of the statement
+to which they pertain:
+
+ statement; /* comment */
+
+We don't use C++ style ("//") comments. We have, however,
+used them in the past in some now-abandoned MMX assembler
+code.
+
+Functions and their curly braces are not indented, and
+exported functions are marked with PNGAPI:
+
+ /* This is a public function that is visible to
+ * application programmers. It does thus-and-so.
+ */
+ void PNGAPI
+ png_exported_function(png_ptr, png_info, foo)
+ {
+ body;
+ }
+
+The prototypes for all exported functions appear in png.h,
+above the comment that says
+
+ /* Maintainer: Put new public prototypes here ... */
+
+We mark all non-exported functions with "/* PRIVATE */"":
+
+ void /* PRIVATE */
+ png_non_exported_function(png_ptr, png_info, foo)
+ {
+ body;
+ }
+
+The prototypes for non-exported functions (except for those in
+pngtest) appear in
+pngpriv.h
+above the comment that says
+
+ /* Maintainer: Put new private prototypes here ^ */
+
+We put a space after the "sizeof" operator and we omit the
+optional parentheses around its argument when the argument
+is an expression, not a type name, and we always enclose the
+sizeof operator, with its argument, in parentheses:
+
+ (sizeof (png_uint_32))
+ (sizeof array)
+
+Prior to libpng-1.6.0 we used a "png_sizeof()" macro, formatted as
+though it were a function.
+
+To avoid polluting the global namespace, the names of all exported
+functions and variables begin with "png_", and all publicly visible C
+preprocessor macros begin with "PNG". We request that applications that
+use libpng *not* begin any of their own symbols with either of these strings.
+
+We put a space after each comma and after each semicolon
+in "for" statements, and we put spaces before and after each
+C binary operator and after "for" or "while", and before
+"?". We don't put a space between a typecast and the expression
+being cast, nor do we put one between a function name and the
+left parenthesis that follows it:
+
+ for (i = 2; i > 0; --i)
+ y[i] = a(x) + (int)b;
+
+We prefer #ifdef and #ifndef to #if defined() and #if !defined()
+when there is only one macro being tested. We always use parentheses
+with "defined".
+
+We prefer to express integers that are used as bit masks in hex format,
+with an even number of lower-case hex digits (e.g., 0x00, 0xff, 0x0100).
+
+We prefer to use underscores in variable names rather than camelCase, except
+for a few type names that we inherit from zlib.h.
+
+We do not use the TAB character for indentation in the C sources.
+
+Lines do not exceed 80 characters.
+
+Other rules can be inferred by inspecting the libpng source.
+
+.SH XVI. Y2K Compliance in libpng
+
+April 25, 2013
+
+Since the PNG Development group is an ad-hoc body, we can't make
+an official declaration.
+
+This is your unofficial assurance that libpng from version 0.71 and
+upward through 1.6.2 are Y2K compliant. It is my belief that earlier
+versions were also Y2K compliant.
+
+Libpng only has two year fields. One is a 2-byte unsigned integer
+that will hold years up to 65535. The other, which is deprecated,
+holds the date in text format, and will hold years up to 9999.
+
+The integer is
+ "png_uint_16 year" in png_time_struct.
+
+The string is
+ "char time_buffer[29]" in png_struct. This is no longer used
+in libpng-1.6.x and will be removed from libpng-1.7.0.
+
+There are seven time-related functions:
+
+ png_convert_to_rfc_1123() in png.c
+ (formerly png_convert_to_rfc_1152() in error)
+ png_convert_from_struct_tm() in pngwrite.c, called
+ in pngwrite.c
+ png_convert_from_time_t() in pngwrite.c
+ png_get_tIME() in pngget.c
+ png_handle_tIME() in pngrutil.c, called in pngread.c
+ png_set_tIME() in pngset.c
+ png_write_tIME() in pngwutil.c, called in pngwrite.c
+
+All appear to handle dates properly in a Y2K environment. The
+png_convert_from_time_t() function calls gmtime() to convert from system
+clock time, which returns (year - 1900), which we properly convert to
+the full 4-digit year. There is a possibility that applications using
+libpng are not passing 4-digit years into the png_convert_to_rfc_1123()
+function, or that they are incorrectly passing only a 2-digit year
+instead of "year - 1900" into the png_convert_from_struct_tm() function,
+but this is not under our control. The libpng documentation has always
+stated that it works with 4-digit years, and the APIs have been
+documented as such.
+
+The tIME chunk itself is also Y2K compliant. It uses a 2-byte unsigned
+integer to hold the year, and can hold years as large as 65535.
+
+zlib, upon which libpng depends, is also Y2K compliant. It contains
+no date-related code.
+
+
+ Glenn Randers-Pehrson
+ libpng maintainer
+ PNG Development Group
projects / wxWidgets.git / blobdiff