[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1067614: texlive-latex-extra: pdfcomment docs reference the cloud instead of local files; also font option broken



Package: texlive-latex-extra
Version: 2020.20210202-3
Severity: normal
X-Debbugs-Cc: debbug.texlive-latex-extra@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


Reply to: