-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
# converting to %23 in links to external PDFs #110
Comments
You didn't provide a test document but I tried
with pdflatex texlive 2019 and using firefox to read the pdf the link works and opened the document on the requested page. It may be a failing in your pdf viewer hard to say with no information. |
Please always show a complete example. |
Minimum working example\documentclass{article}
\usepackage{hyperref}
\begin{document}
\href{https://www.google.com/#searchform}{Google followed by /\#searchform.}
\end{document} ResultSystem
|
@tchlux sorry but texlive 2016 is old. In a current texlive with a current hyperref it works fine for me. |
(continued from my post above)Installed TeX Live 2019 ( @u-fischer did you test with the PDF viewers in Safari or Preview? Installed the Firefox web browser ( System
|
Using this pdf file (hyperref-hash-in-url.pdf) produced by running
no matter which one of the three browsers Chrome v79.0.3945.130, Safari v13.0.4, and FireFox v73.0.1 is set to be the default browser. I am in macOS 10.15.2. So this might be an issue with the encoding used in url, or with different pdf readers.
On my side, when using Preview.app with FireFox, the link dose not works correctly. Other infoWith the help of python library PyPDF2, the following python script prints #!/usr/bin/env python3
from PyPDF2 import PdfFileReader
f_in = 'hyperref-hash-in-url.pdf'
pdf = PdfFileReader(f_in)
page = pdf.getPage(0)
annot = page['/Annots'][0].getObject()
print(annot['/A']['/URI']) By the URL Standard, sec. 4.3, the U+0023 (#) before url-fragment string in each valid url should always be explicit, not percent-encoded. Hence the behaviors of all three tested browsers are also alright.
|
I'm on windows. But as @muzimuzhi wrote: The url in the pdf is correctly encoded. So the problem must be due to a bug of your pdf viewer. |
This issue also popped up a few days ago in stackexchange (link), where the |
@muzimuzhi when I say "viewing the document", I mean that I am viewing the PDF within Firefox, and clicking the linked text simply traverses the link in the same tab. Our outcomes agree. Thanks for the thorough tests! I agree with @PhelypeOleinik, this appears to be a bug in Preview, Safari, TexShop, and Skim where the |
@tchlux while it may be a pdf reader issue primarily, that doesn't mean it is necessarily impossible that something could be done from this side. In particular is it possible to make (or find) PDF made with other applications that do have # fragid links in URL that work here, if so we could look what internal PDF markup they are using..... (I don't have easy access to a Mac to try myself). |
In briefThe following info indicates that
Hence I have reported to Apple through its "Feedback Assistant.app". It seems this report is not publicly accessible. Accumulated test results, under macOS
Other version info
About Skim, the macOS only pdf readerI have found a similar bug reported to Skim in Nov 2019, and the maintainer of Skim responded that it is a bug from Apple
About encodings used in URL (or URI)From the PDF Reference, in a URI Action,
From RFC 3986, sec. 2.2 (which obsoletes RFC 2396), hash (U+0023,
Also, prepend
|
Update: This post just further verifies what @muzimuzhi says above. @davidcarlisle good point. I have run some more tests involving "printing" a web page to a PDF with different browsers. Here is my test webpage: <a href="https://www.google.com/#searchform">Google fragment ID link</a> When generating PDFs with different browsers, here are the results: 'Printed' with Google Chrome, Version 80.0.3987.122 (Official Build) (64-bit)PDF 'Viewed' with:
'Printed' with Firefox, Version 73.0.1 (64-bit)Link is not included in the output PDF. 'Printed' with Safari, Version 13.0.5 (15608.5.11)The URL within the file has had I see this as further evidence that Safari, Preview, TexShop, and Skim are bugged and there isn't an easy way around the issue. If someone has a reason to believe they have a PDF with working |
Same problem here.
MacOS with Skim as pdf-reader Anyone knows how to solve this? |
I'm also struggling with this issue ( |
@wsdewitt if you use only the url package there are no real links (annotations) in the pdf. The pdf viewer will then simply guess that some text is perhaps meant to be a link. This can also work if you simply type |
OIC, so that's just Preview parsing the link. |
I have the same issue with a document compiled with xelatex from TeX Live 2019 on macOS 10.15.5. |
This is as the discussion shows not an hyperref issue: it creates the correct link. But some pdf viewers on mac don't handle this correctly. The problem should be reported elsewhere and I'm closing here. |
I encountered this issue as well. I was not using hyperref, but it was a major cause for concern since the majority of the audience that we were reaching utilized Safari on iOS, the workaround we came to was using a bitly link. |
That's a great idea. Thanks! |
I am trying to link to a particular page of a PDF file. If you cut and paste the following link in your browser, it loads the file and scrolls to the correct page:
https://edca.3dca.flcourts.org/DcaDocs/2019/0248/2019-248_Brief_230675_RC09202D20Record20on20Appeal.pdf#page=298
I try to link to the file in LaTeX / hyperref:
But when the document compiles and I click the link, the # gets converted to %23 in the browser, and the PDF does not load on the external server. The same thing happens if I escape #.
I don't recall this happening before. Shouldn't the hyperlink above render exactly as written?
The text was updated successfully, but these errors were encountered: