For an unadvertised reason, /usr/share/doc/texlive-doc/latex/webquiz/examples/*.png and /usr/share/doc/texlive-doc/latex/beautybook/inner_pics/titleimages/songeven.png have caNv chunks. This chunk is not standard and creates issues down certain tool chains; cf. http://bugs.debian.org/1115346. The documentations opened by `texdoc webquiz` and `texdoc beautybook` keep silent about this tag. If this tag is really necessary, document why; otherwise, remove it from the offending PNG files (`pngcrush -brute -ow -rem caNv file.png`).

Am 04.06.26 um 18:24 schrieb Norbert Preining:
Sorry, wrong question. The right question is: “Why shipping nonstandard stuff in the first place”? On my installation, only the TeX-Live documentation has this issue, whereas all PNG files in all the other packages on my system are fine with regard to the absence of caNv.
I appreciate your work, and I'm surprised that you question the standard procedure, which is to report a bug to the operating-system maintainers first. You may check whether the issue is present in the development version of the packages and, if it is present, report upstream (or ask someone else, including me, to do this), but you shouldn't complain about a user filing a bug against a Debian package in the first place.
As examples. In general, you don't know how the images are going to be used in the end. http://bugs.debian.org/1115346 documents what goes wrong silently in a particular conversion (it gets worse if there are more conversions, as caNv is reported by `pngcheck -v` as safe to copy), and a user may notice the error years after having shipped a wrong output.

Upon further checking, I take back my claim on /usr/share/doc/texlive-doc/latex/beautybook/inner_pics/titleimages/songeven.png. Though this file does contain the 4 letters “caNv”, it's not a chunk.  So beautybook is fine.

The 40 PNG files in /usr/share/doc/texlive-doc/latex/webquiz/examples do contain caNv as a chunk as per `pngcheck -v`. So the only culprit is webquiz.

I didn't say “violation”. I wrote “nonstandard stuff”, which is fine in plain English; a more precise term would be “stuff void of semantics” or “semantics-less stuff”. You could also say “unknown private” and “ancillary” if you wish to stick to the terminology set by §5.4 of the PNG spec. I also wrote “pointless”. The caNv chunks in /usr/share/doc/texlive-doc/latex/webquiz/examples/*.png are like a biohazard in a bin tagged “don't open” - all goes well until someone, having his/her own logic, opens the bin. So if these caNv chunks serve some purpose - sure, state the purpose and go for it, but if they don't, let's simply get rid of the garbage. As of now, `convert /usr/share/doc/texlive-doc/latex/webquiz/examples/<whatever>.png /tmp/<whatever>.pdf` produces a PDF with unexpectedly large margins.

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.

Am 06.06.2026 um 04:58 schrieb Md Ayquassar:

Hello,

I don't really intend to ignore issues, however I'm the only TL
maintainer in Debian and I'm quite busy packaging TL (and a few other
packages). Therefore I'm very thankful, if submitters are willing to
contact the upstream authors themself. Mostly submitters have understood
the issue better than me, so they can argue much better than me (if needed).
Are you willing to open a ticket at github[1]? You /may/ leave the issue
to me, but there is a high danger, that I put it on the stack and it
will remain there for an indefinite time.

Thanks,
   Hilmar

[1] AndrewAtLarge/WebQuiz/issues

Am 07.06.26 um 13:36 schrieb Preuße, Hilmar:
Github said, “We're unable to create an account with this email address.” So I wrote a private e-mail to the author and cc'ed Hilmar.

Am 09.06.2026 um 08:03 schrieb Md Ayquassar:

Hello,
Sorry, I wasn't aware of this. I've created now an issue on github.

Hilmar