view release on metacpan or  search on metacpan

src/Source/LibPNG/libpng-manual.txt  view on Meta::CPAN

The replacement I/O functions must have prototypes as follows:

    void user_read_data(png_structp png_ptr,
        png_bytep data, png_size_t length);

    void user_write_data(png_structp png_ptr,
        png_bytep data, png_size_t length);

    void user_flush_data(png_structp png_ptr);

The user_read_data() function is responsible for detecting and
handling end-of-data errors.

Supplying NULL for the read, write, or flush functions sets them back
to using the default C stream functions, which expect the io_ptr to
point to a standard *FILE structure.  It is probably a mistake
to use NULL for one of write_data_fn and output_flush_fn but not both
of them, unless you have built libpng with PNG_NO_WRITE_FLUSH defined.
It is an error to read from a write stream, and vice versa.

Error handling in libpng is done through png_error() and png_warning().
Errors handled through png_error() are fatal, meaning that png_error()
should never return to its caller.  Currently, this is handled via
setjmp() and longjmp() (unless you have compiled libpng with
PNG_NO_SETJMP, in which case it is handled via PNG_ABORT()),
but you could change this to do things like exit() if you should wish,
as long as your function does not return.

On non-fatal errors, png_warning() is called
to print a warning message, and then control returns to the calling code.
By default png_error() and png_warning() print a message on stderr via
fprintf() unless the library is compiled with PNG_NO_CONSOLE_IO defined
(because you don't want the messages) or PNG_NO_STDIO defined (because
fprintf() isn't available).  If you wish to change the behavior of the error
functions, you will need to set up your own message callbacks.  These
functions are normally supplied at the time that the png_struct is created.
It is also possible to redirect errors and warnings to your own replacement
functions after png_create_*_struct() has been called by calling:

    png_set_error_fn(png_structp png_ptr,
        png_voidp error_ptr, png_error_ptr error_fn,
        png_error_ptr warning_fn);

    png_voidp error_ptr = png_get_error_ptr(png_ptr);

If NULL is supplied for either error_fn or warning_fn, then the libpng
default function will be used, calling fprintf() and/or longjmp() if a
problem is encountered.  The replacement error functions should have
parameters as follows:

    void user_error_fn(png_structp png_ptr,
        png_const_charp error_msg);

    void user_warning_fn(png_structp png_ptr,
        png_const_charp warning_msg);

The motivation behind using setjmp() and longjmp() is the C++ throw and
catch exception handling methods.  This makes the code much easier to write,
as there is no need to check every return code of every function call.
However, there are some uncertainties about the status of local variables
after a longjmp, so the user may want to be careful about doing anything
after setjmp returns non-zero besides returning itself.  Consult your
compiler documentation for more details.  For an alternative approach, you
may wish to use the "cexcept" facility (see http://cexcept.sourceforge.net),
which is illustrated in pngvalid.c and in contrib/visupng.

Beginning in libpng-1.4.0, the png_set_benign_errors() API became available.
You can use this to handle certain errors (normally handled as errors)
as warnings.

    png_set_benign_errors (png_ptr, int allowed);

    allowed: 0: treat png_benign_error() as an error.
             1: treat png_benign_error() as a warning.

As of libpng-1.6.0, the default condition is to treat benign errors as
warnings while reading and as errors while writing.

Custom chunks

If you need to read or write custom chunks, you may need to get deeper
into the libpng code.  The library now has mechanisms for storing
and writing chunks of unknown type; you can even declare callbacks
for custom chunks.  However, this may not be good enough if the
library code itself needs to know about interactions between your
chunk and existing `intrinsic' chunks.

If you need to write a new intrinsic chunk, first read the PNG
specification. Acquire a first level of understanding of how it works.
Pay particular attention to the sections that describe chunk names,
and look at how other chunks were designed, so you can do things
similarly.  Second, check out the sections of libpng that read and
write chunks.  Try to find a chunk that is similar to yours and use
it as a template.  More details can be found in the comments inside
the code.  It is best to handle private or unknown chunks in a generic method,
via callback functions, instead of by modifying libpng functions. This
is illustrated in pngtest.c, which uses a callback function to handle a
private "vpAg" chunk and the new "sTER" chunk, which are both unknown to
libpng.

If you wish to write your own transformation for the data, look through
the part of the code that does the transformations, and check out some of
the simpler ones to get an idea of how they work.  Try to find a similar
transformation to the one you want to add and copy off of it.  More details
can be found in the comments inside the code itself.

Configuring for gui/windowing platforms:

You will need to write new error and warning functions that use the GUI
interface, as described previously, and set them to be the error and
warning functions at the time that png_create_*_struct() is called,
in order to have them available during the structure initialization.
They can be changed later via png_set_error_fn().  On some compilers,
you may also have to change the memory allocators (png_malloc, etc.).

Configuring zlib:

There are special functions to configure the compression.  Perhaps the
most useful one changes the compression level, which currently uses
input compression values in the range 0 - 9.  The library normally