Wow, the venerable “it's in the spec” defense—ever the trusty shield for those who mistake private and experimental for standard.
Since routine image processing apparently surpasses the purview of TeX Live upstream curation, allow me to clarify. These caNv chunks are not some arcane necessity. They are private, experimental metadata—leftover canvas instructions from some software's behavior, probably that of taking or processing screenshots. I'd be happy to be proven wrong, but to my knowledge, these chunks serve precisely zero purpose in the final webquiz documentation. Your theoretical insistence that decoders “must ignore” these chunks is charming, but it wilts in the face of reality. convert does not ignore caNv. It processes it, as intended when support was added (cf. https://git.codelinaro.org/clo/la/platform/external/ImageMagick/-/blame/630cb567239b90b48ec194215997969313988887/ChangeLog?page=1), and the result is bogus contents in PDFs (http://bugs.debian.org/1115346). Furthermore, the offsets in these chunks survive `-strip`; cf. https://jqmagick.imagemagick.org/discourse-server/viewtopic.php?t=31277. So the Debian's preferred tool acknowledges they are not simply discardable metadata. They persist and poison the output. This isn't about a “crusade” against a “favorite program”. It is about package hygiene. Shrugging and declaring that TeX Live “takes what the author provides” is merely a confession of negligence. The PNG specification permits private chunks—it does not compel you to ship digital detritus that sabotages standard Debian workflows. So, instead of lecturing users about a spec fantasy, simply check with the webquiz authors, and if they don't respond, chdir to webquiz/examples and run `for file in *.png; do pngcrush -brute -ow -rem caNv $file; done` yourself. Or continue with the bloat and enjoy the trash when innocently converting. Upstream either takes responsibility or does not. The choice is yours.
