There are a number of png files in TDE that generate errors on opening due to outdated png header information. I would like to identify which icons these are. For example when opening khelpcenter I receive the following messages:
03:03 valhalla:~> khelpcenter help:/khelpcenter/releasenotes khelpcenter: WARNING: Main template file name is empty. libpng warning: iCCP: known incorrect sRGB profile libpng error: IDAT: invalid distance too far back libpng error: IDAT: invalid distance too far back libpng error: IDAT: invalid distance too far back libpng warning: Interlace handling should be turned on when using png_read_image libpng error: IDAT: invalid distance too far back libpng error: IDAT: invalid distance too far back libpng error: IDAT: invalid distance too far back libpng warning: Interlace handling should be turned on when using png_read_image
Apparently, the problem is out-of-date png header information. Searching I stumbled across a minimal bit of source that is supposed to fix the issue, but only if compiled on older versions of libpng. Looking at the code, the crux of it is to rewrite the first 8 bytes of the png header. I've attached it for experimentation. It builds well on all of the boxes I have, but I suspect you have to force it to build against libpng 1.2 in order for it to do what it is supposed to. I'll continue to experiment. If you have few spare minutes give it a try and let me know if you can see any discernible difference in the new/old png files. I haven't yet.
This is a bug report against newer versions of libpng. I don't seen any such errors with libpng 1.4.12.
I suspect a rite of initiation to become a libpng developer is to introduce new code that breaks something for everybody downstream. Cousins to the BOFH.
Darrell
On 02/11/2014 10:37 PM, Darrell Anderson wrote:
This is a bug report against newer versions of libpng. I don't seen any such errors with libpng 1.4.12.
I suspect a rite of initiation to become a libpng developer is to introduce new code that breaks something for everybody downstream. Cousins to the BOFH.
I cannot think of anything worse to break to cause unholy hell for all developers alike other than breaking gcc or jpeg. Sheeze, I know it is for the greater good of the future, and preventing exploits, blah, but those type of FUBARs literally cost hundreds of thousands if not millions of manhours to implements. In those cases every piece of software being built that contains a png will have to be modified. I'm sure the png devs were not on any Christmas lists (or other holiday lists) for the past few years...