Tk Source Code

screenshots generated on a mac via standard shortcuts, full screen as well as clipped regions (standard key bindings shift-command-4 for region selection, shift-command-3 for full screen, I believe), are in png format. such screenshots create a Tk error:

package require Tk
image create photo -file problem.png     ;# ==> encountered an unsupported criticial chunk type "iDOT".

the same png-image is accepted by img::png without problems. I will try to provide a small example png-file in the next step

Merged to core-8-6-branch and trunk.

I didn't find a way to download this image from the ticket without my browser tampering with it, which prevented me from reproducing with that image.

However the OP sent me the image (thanks!) and I could then reproduce.

This is now fixed in branch bug-1c659ef0f1. The problem was that the wrong bit was tested when checking for ancillary (i.e. starting with a lowercase letter) chunks. Now 'iDOT' starting by a lowercase letter is correctly recognized as an ancillary chunk, and as such is properly silently ignored since it is not known.

I have added a new testcase imgPNG-3.1 that fails before the fix, and succeeds with the fix. This test uses the test image provided by the OP (and renamed as 'iDOT.png'). No img*|photo* test newly fails with this fix (I see exactly 0 failures on Vista).

Sorry, there is an already attached image supposed to trigger the issue.

However I cannot reproduce with this image. Perhaps a download issue?

Quick analysis looks like a patch fixing this sould be:

Index: generic/tkImgPNG.c
==================================================================
--- generic/tkImgPNG.c
+++ generic/tkImgPNG.c
@@ -33,11 +33,11 @@

 /*
  * Chunk type flags.
  */

-#define PNG_CF_ANCILLARY 0x10000000L   /* Non-critical chunk (can ignore). */
+#define PNG_CF_ANCILLARY 0x20000000L   /* Non-critical chunk (can ignore). */
 #define PNG_CF_PRIVATE   0x00100000L   /* Application-specific chunk. */
 #define PNG_CF_RESERVED  0x00001000L   /* Not used. */
 #define PNG_CF_COPYSAFE  0x00000010L   /* Opaque data safe for copying. */

 /*

I need to study this more though.

It would really help if an image triggering the problem would be attached to this ticket.

dkf opinion got published in comp.lang.tcl as follows:

This is a reportable bug (hopefully you've got a small unimportant image that triggers this). The bug is that it shouldn't be reported as a critical chunk as the initial letter is lower case; it ought to have been interpreted as an ancillary chunk and ignored.
(It seems that the “iDOT” chunk type is some Apple-specific extension that isn't marked as a proper vendor extension and nobody else knows what to do with it other that ignore or delete it. Or sabotage it. It's theorised that it relates to something to do with the screen resolution for HighDPI displays.)

(You meant: a reply on the usenet group comp.lang.tcl, rather than on the Tcl mailing list)

After a quick glance at the source code, this does not look hard to do.

Before going that way however, I'd like to get opinion from dkf (he is the one who implemented TIP #244 with Michael Kirkham).

I've got a reply on the tcl mailing list which is of relevance. the main info can be found here:

https://stackoverflow.com/questions/33894790/what-is-the-idot-chunk

so it seems it is indeed a specific Apple/Mac problem and maybe restricted to retina displays (yes, I am using one, too).

despite this being Apple violating naming conventions, maybe it would be possible to just ignore that special chunk just as, seemingly, libpng is doing since libpng based tools work just fine with those screendumps?