[NTG-pdftex] writepng problem?

Hartmut Henkel hartmut_henkel at gmx.de
Mon Nov 1 08:34:54 CET 2004


On Mon, 1 Nov 2004, Akira Kakuto wrote:

> On windows (1.20b-beta, libpng-1.2.7),
> ????4a??.png were ng and ????6a??.png were ok:
>
> > here it seems that pdftex currently crashes on Willem van Schaik PNG
> > test files
> >
> > basn4a08.png 8 bit grayscale + 8 bit alpha-channel
> > basn4a16.png 16 bit grayscale + 16 bit alpha-channel
>
> ng
>
> > basn6a08.png 3x8 bits rgb color + 8 bit alpha-channel
> > basn6a16.png 3x16 bits rgb color + 16 bit alpha-channel
> > bgan6a08.png 3x8 bits rgb color, alpha, no background chunk
> > bgan6a16.png 3x16 bits rgb color, alpha, no background chunk
>
> ok
>
> > bgbn4a08.png 8 bit grayscale, alpha, black background chunk
> > bggn4a16.png 16 bit grayscale, alpha, gray background chunk
>
> ng
>
> > bgwn6a08.png 3x8 bits rgb color, alpha, white background chunk
> > bgyn6a16.png 3x16 bits rgb color, alpha, yellow background chunk
>
> ok

Thanks a lot! Yes, i have lied a little, haven't actually checked all
these for crashes, but the ones with "ok" also have these potentially
harmful buffer overflows, which i tested by

        /* extend buffer by 100 bytes */
        row = xtalloc(png_info(img)->rowbytes + 100, png_byte);
        /* pre-fill at the end */
        for (u = 0; u < 100; u++)
            row[png_info(img)->rowbytes + u] = u;
        for (i = 0; i < (int) png_info(img)->height; i++) {
            row_pointers[0] = row;
            png_read_rows(png_ptr(img), row_pointers, NULL, 1);
            /* look what has been overwritten by libpng */
            for (u = 0; u < 100; u++)
                printf("%d ", row[png_info(img)->rowbytes + u]);
         ...}

in function write_png(). All above files cause libpng to write beyond
the allocated row buffer by 32 bytes (for these files). The increased
line length seems to be caused by the alpha stuff, which is not
stripped, by accident.

Cure might be (recommended by the PNG list) to set a background instead
of stripping alpha, but that might require more work to make it
compatible with the PDF specification. One needs 3-component colors,
RGB, and a way that libpng does this cleanly by handling the background,
maybe the one specified by the background chunk coming with the file (or
white?). And the original way of simply stripping alpha is considered
more as a kludge anyway (e. g. garbage disabled by alpha would suddenly
be visible). Still it's a pity that such a backward-incompatible news
was silently introduced to libpng...

Regards, Hartmut


More information about the ntg-pdftex mailing list