2

I am not sure if this is an issue with how web sites are configured, or the hyperref pacakge. The following two links are correct (which you can verify by copying the first paramater to \href{}{} and pasting in a browser.

\href{https://en.wikipedia.org/wiki/Global_warming#Regional_trends}{Climate Change: Regional Trends}

\href{http://www.imperial.ac.uk/a-z-research/#group-M}{A-Z Research: Group M}

However, clicking on the pdf file for the second link does not work. It seems as if the offending link that is attempted to be opened is

http://www.imperial.ac.uk/a-z-research/%23group-M

where the # has been replaced with a %23. However, the Wikipedia link seems to be displayed with the # in the URL.

So, is there anything I can do when generating the PDF to get both of these links to correctly work. Preferrably I can do this without having to manually click on the link and determine if tweaking is required.

Code:

\documentclass{article}
\usepackage{hyperref}

\begin{document}

\href{https://en.wikipedia.org/wiki/Global_warming#Regional_trends}{Climate Change: Regional Trends}

\href{http://www.imperial.ac.uk/a-z-research/#group-M}{A-Z Research: Group M}

\end{document}
  • 2
    works fine for me. How are you compiling? – Ulrike Fischer Jan 29 at 19:49
  • @UlrikeFischer: With pfdlatex. Are you sure that clicking on the second link takes you to the same page as cutting and pasting the URL? The 404 error page has the similar formatting to the actual page, but different content. – Peter Grill Jan 29 at 19:51
  • 2
    I recently had a similar issue with a Mac user who used some PDF viewer which had a tendency to escape # in URLs. So this might be viewer dependant. Which PDF reader do you use? – Marcel Krüger Jan 29 at 19:51
  • 1
    @MarcelKrüger: Yes, I am on a Mac and using the pdf viewer built into TeXShop. Hmmm, you are correct. This is a problem with the TeXShop pdf viewer. Acrobat link seems to work just fine. Interesting that the first link works. – Peter Grill Jan 29 at 19:52
  • 4
    I use MacTeX2019, TeXshop 4.44, and TeXworks 0.6.3 (as well as various Adobe pdf viewers). I can confirm that (a) TeXshop's built-in pdf viewer cannot handle the second hyperlink correctly and (b) TeXwork's pdf viewer (and Adobe Reader and Acrobat) do just fine, with both hyperlinks. – Mico Jan 29 at 20:01
2

It appears that in current versions (March 2020) of Preview, Safari, TexShop, and Skim, any # symbols are (incorrectly) converted to %23 when the link is clicked. It is safe to call this a bug in all four applications, considering the following:

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.

A valid URL string must be either a relative-URL-with-fragment string or an absolute-URL-with-fragment string. - A relative-URL-with-fragment string must be a relative-URL string, optionally followed by U+0023 (#) and a URL-fragment string. - An absolute-URL-with-fragment string must be an absolute-URL string, optionally followed by U+0023 (#) and a URL-fragment string.

Originally posted by @muzimuzhi in https://github.com/latex3/hyperref/issues/110#issuecomment-593082128

| improve this answer | |
0

As per the comments this is an issue with the TeXShop pdf viewer as clicking the link in Acrobat seems to work.

| improve this answer | |
  • @MaxPowers: TeXShop uses the Mac's pdfkit, which Preview also must be using. – Peter Grill Aug 2 at 17:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.