Re: pngcp and pngfix still need fixing (following up: libpng version 1.6.38)

John Bowler <[email protected]> Sun, 18 Sep 2022 19:21:13 -0700
Newsgroups gmane.comp.graphics.png.devel
Message-ID <CAP7U39-MV5jvEv7NPV1DRxpHMLNWFdhwnzremoKFTo_uQDS4Zg@mail.gmail.com>
> pngcp is marked as a test program in Makefile.am, and yet, some of the
external libpng building and packaging developers insist on shipping it,
alongside pngfix and png-fix-itxt. The fact that pngcp and
pngfix/png-fix-itxt are in the same contrib directory doesn't help. I
suppose that either renaming pngcp to something else (e.g. pngcopy) and/or
moving it to a different directory *could* help.

pngcp is probably the most useful because I believe it will end up
stripping out all the stuff that people erroneously put in there because
they still use libpng 0.95c, pngfix just requires too much knowledge (i.e.
reading) and png-fix-itxt.  Of course pngcp doesn't have an accessible help
message, which is maybe good, although it does seem to be accepting eXIf,
which is actually in pngtest.png (even though clearly non-approved, like
vpAg, which pngcp doesn't remove either).

Quite frankly I can't remember how it worked; it was just a quick example I
wrote primarily for testing.  The fact that it is over 2000 lines of code
perhaps just illustrates the problems with the original API; pngimage.c is
only 1700 lines and is a real test program (but, unlike pngcp.c, it has
very few comments; it's a test, not an example.)

The *safe* approach is to replace all these programs with something called
something unique, png-copy-and-fix-any-png-file, for example, and have that
use the simplified API to just make a copy; i.e. decompress then recompress
without changing the format.  Put that in the main directory.

_______________________________________________
png-mng-implement mailing list
png-mng-implement-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-implement