+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 IX. 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.
+
+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 X. 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.
+
+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
+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. Applications that need access
+to information in zlib.h will need to add the '#include "zlib.h"'
+directive. It does not matter whether it is placed prior to or after
+the '"#include png.h"' directive.
+
+We moved the png_strcpy(), png_strncpy(), png_strlen(), png_memcpy(),
+png_memcmp(), png_sprintf, and png_memcpy() 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.
+
+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 XI. 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 XII. 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://libpng.git.sourceforge.net/gitroot/libpng
+
+or you can browse it via "gitweb" at
+
+ http://libpng.git.sourceforge.net/git/gitweb.cgi?p=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 XIII. 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 ^ and in libpngpf.3 */
+
+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 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 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 XIV. Y2K Compliance in libpng
+
+December 15, 2011
projects / wxWidgets.git / blobdiff