4

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}
6
  • 2
    works fine for me. How are you compiling? Commented Jan 29, 2020 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. Commented Jan 29, 2020 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? Commented Jan 29, 2020 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. Commented Jan 29, 2020 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
    Commented Jan 29, 2020 at 20:01

2 Answers 2

4

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

0

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

1
  • @MaxPowers: TeXShop uses the Mac's pdfkit, which Preview also must be using. Commented Aug 2, 2020 at 17:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .