Bug#1138817: Remove pointless caNv tags
Md Ayquassar <[email protected]> Fri, 5 Jun 2026 02:15:54 +0200
| Newsgroups | gmane.linux.debian.devel.tetex |
|---|---|
| Message-ID | <967395de-1e1e-4098-b235-a5160bcb8ed6__34783.4519621514$1780618653$gmane$org@ro.ru> |
Am 04.06.26 um 18:24 schrieb Norbert Preining: > On Thu, 04 Jun 2026, Md Ayquassar wrote: >> 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`). > > Sorry, why? 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. > an up-upstream bug, not TeX Live, but > upupstream webquiz and beautybook authors, so should be reported there > and not here. 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. > This are file in the documentation hierarchy in TeX Live. > Why is any tool at all using these files at all? 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.