Package: texlive-latex-extra Version: 2020.20210202-3 Severity: normal X-Debbugs-Cc: debbug.texlive-latex-ex...@sideload.33mail.com
There is a Debian-specific bug in the manual located here: /usr/share/doc/texlive-doc/latex/pdfcomment/pdfcomment.pdf Page 7 links to example.pdf here: http://mirror.ctan.org/macros/latex/contrib/pdfcomment/doc/example.pdf It references the cloud location when in fact there is a local copy of example.pdf in the same directory as the manual itself. This occurs in a few other places in the manual, such as page 12. The links should reference the local file so there is no network dependency. Anything can go wrong with links into the cloud, such as websites joining Cloudflare (which then denies access to several demographics of people). Apart from that minor issue, there’s a bigger problem upstream. The “font” option is somewhat broken. Use of the font option produces documents that only render correctly in Adobe Acrobat. Bug 1067612 gives more detail, sample code, and sample output: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067612 Poppler is apparently dropping the ball on fonts, even the so-called 14 standard fonts that the manual claims are safe. The manual needs to go further to clarify and warn. I wasted a lot of time trying to figure out why even the most mainstream fonts were not rendering before someone told me to try Acrobat. There is very likely a defect in pdfcomment that cause a giant arrow to appear in the middle of every page where \pdffreetextcomment is used. It’s apparent in the attachments to bug 1067612: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1067612;filename=example_Acro.djvu;msg=5 https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=1067612;filename=annotation_font_samples_Acro.djvu;msg=5 It’s also worth noting that the default font isn’t good for the annotation purpose. An uppercase “I” is just a vertical bar which is indistinguishable from a digit 1 or lowercase “l”. It’s not a good default to be trapped with for annotations where you do not generally have much text to infer context. E.g. if a lawyer wants to label something “Exhibit I” there can be confusion.. is that Exhibit 1 or Exhibit “l”? There is a problem when pdfcomment is imported before the datetime2 package. This causes an option clash error: \usepackage{pdfcomment} \usepackage[calc,useregional]{datetime2} But if that sequence is reversed, there is no error. I’m not sure if that’s something that needs to be fixed in the code, but if not then I suggest noting the idiosyncracy in the manual because it can be tricky for users to sort out the problem. I tried to report the upstream-specific bugs upstream. It was a disaster. Hence why this bug report herein is a blend of upstream and downstream bugs. I followed this process in attempt to register on bitbucket: ① solved a CAPTCHA just to reach a reg. form (I have image loading disabled but the graphical CAPTCHA puzzle displayed anyway [Firefox bug?]) ② disposable email address rejected (so Bitbucket can protect themselves from spam but other people cannot?) ③ tried a forwarding acct instead of disposable (accepted) ③ another CAPTCHA emerged, this time Google reCAPTCHA. I never solve these because it violates so many digital right principles and I boycott Google. I made an exception for this experiment. The puzzle was empty because I disable images (can’t afford the bandwidth). Exceptionally, I enable images for this poorly designed website. I managed to solve enough of the ambiguous puzzles to get a pass. ④ got the green checkmark ✓ ⑤ clicked “sign up” ⑥ “We are having trouble verifying reCAPTCHA for this request. Please try again. If the problem persists, try another browser/device or reach out to Atlassian Support.” So Google profited from my labor in solving a reCAPTCHA then my access was refused by Bitbucket anyway. It’s worth noting that the Debian Social Contract (DSC) and Debian Free Software Guidelines (DFSG) condemn discrimination. Blind people cannot likely get passed all those CAPTCHAs to reach the upstream bug tracker. One might say the upstream bug tracker is not Debian’s problem. OTOH, the texlive package (understandably) steers people to file bugs upstream because this beast has the complexity of an OS in itself. But at the same time there’s an infrastructural problem when people are being directed into those shitty upstream walled gardens particularly when thy are discriminatory. I don’t have the answer -- just laying out the problem. It gets worse. So then (step ⑦) I attempted to e-mail the code author: ===8<---------------------------------------- status=bounced (host $authors_own_mx_svr said: 550-host $my_ip is listed at combined.mail.abusix.zone (127.0.0.11); 550 see https://lookup.abusix.com/search?q=$my_ip (in reply to RCPT TO command)) ===8<---------------------------------------- If only the Debian-specific bug is worked and the rest of this report is closed, perhaps that’s fair enough. I’ve gone as far as I’m willing to go. I just want these problems to be recorded /somewhere/ amid the author being unreachable. BTW, there’s perhaps a defect in the Package-specific info that the reportbug tool prints for texlive-latex-extra. It prints this: ===8<---------------------------------------- Please read and follow the instructions in the first lines below the text: "-- Package-specific info:". Thank you. Please don't add attachments > 100KB. They won't make it through our mailing list and we won't see the report! ===8<---------------------------------------- Around 800k of attachments were apparently accepted okay for bug 1067612, so the above-mentioned 100k limit may not be in force. -- System Information: Debian Release: 11.5 APT prefers oldstable-updates APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 'testing'), (990, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages texlive-latex-extra depends on: ii libcommons-logging-java 1.2-2 ii libpdfbox-java 1:1.8.16-2 ii preview-latex-style 12.2-1 ii python3 3.9.2-3 ii tex-common 6.16 ii texlive-base 2020.20210202-3 ii texlive-binaries 2020.20200327.54578-7 ii texlive-latex-recommended 2020.20210202-3 ii texlive-pictures 2020.20210202-3 Versions of packages texlive-latex-extra recommends: ii texlive-fonts-recommended 2020.20210202-3 ii texlive-plain-generic 2020.20210202-3 Versions of packages texlive-latex-extra suggests: pn icc-profiles <none> ii libfile-which-perl 1.23-1 ii libspreadsheet-parseexcel-perl 0.6500-1.1 pn python3-pygments <none> ii texlive-latex-extra-doc 2020.20210202-3 Versions of packages tex-common depends on: ii dpkg 1.20.12 ii ucf 3.0043 Versions of packages tex-common suggests: pn debhelper <none> Versions of packages texlive-latex-extra is related to: ii tex-common 6.16 ii texlive-binaries 2020.20200327.54578-7 -- no debconf information