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