[libpng18] < 10700, not quite complete

[jbowler]

Currently pngvalid and pngstest tests are failing because the libpng 1.7 error limits are being used.

BACKGROUND: libpng17 fixed significant errors in the libpng transforms but did not contain a separate version of either pngvalid or any other test (to misquote Jo Carol Pierce, I blame Glenn).

I'd prefer:

if ... != 10700

the // comments seem just obscure and, since the libpng17 branch does, in fact, have a separate version of the programs (and so it should remain) the issue of anything other than 10700 in this fork will never arise.

[ctruta]

the // comments seem just obscure

Those are bad on purpose: I put them in there quickly to unblock the build, and I made them a deliberate eyesore to ensure that they will be addressed.

Among the many things that I didn't like and that I wanted undone was the extra effort spent for the test programs to be independent of the libpng version that they're testing. No more checking of PNG_LIBPNG_VER, unless it is for a purpose like this:

https://github.com/pnggroup/libpng/blob/68d7ce8040a611e9166890e02ecc409a03d76c2e/pngtest.c#L57

So, the test programs shipped with libpng version A.B.C must work with libpng version A.B.C, nothing less and nothing more, period. Who has ever tested these things to see if they work anywhere else, like, libpng version A.B.D or libpng version P.Q.R?

[ctruta]

I forgot to say the most important thing: If we want to bring libpng-1.7 stuff into libpng-1.8, now would be a good time, wink-wink 😉

[jbowler]

About the version independence I agree completely. Removing all that support for older and newer versions would just make everything more maintainable.

libpng17 is different; what you see in pnggroup/libpng17 is just the tip of the iceberg. I have a massive set of changes beyond that. One thing it does is a "novel" (well, damned obvious) way of handling filtering. It is not necessary on read to save the previous row :-) Another is to do transforms completely differently; the transform code gets blocks of pixels, not the whole row. "Defiltering" on read is just the first transform step.

Another thing is not to check chunks unless they are png_get'ed; why bother reporting bugs when the app never uses the chunk?

So libpng17 is must more like libpng20; maybe not libpng-ng because at present it maintains the API compatibility, but I'd relax that. Some issues are that "png_get_valid" lists all the known chunks which required the validation to be done if the app called it (as opposed to just calling png_get_foo). Another issue is the "user transform" API and the "unknown handling" APIs; massive complexity which inhibits development.

I don't think we want any of that in libpng18; it's just there for all the ABI breakers and a few "quiet" API changes. For example I would like warning and error messages to only get turned "on" if the user of libpng sets up appropriate handling. A good release schedule would be when W3C PNG 3 is finalized and implementations of the three new chunks are available.

I could also put in very-very basic APNG chunk support. This can only be done in a major release because it would break libpng16 by handling a chunk which is "in the wild" and therefore, we assume, has to be handled by one or other of the unknown handlers. I'd like there to be some guy implementing "libapng" to provide direction; there are some internal details because at present png_write_end swallows up all the APNG frames and sticks them in memory.