#1429 broken hyperlinks

[Ryo]

There are many hyperlinks in the attached PDF file and some of the links don't work on Skim whereas they do work on Acrobat Reader. Those which don't work include special characters. Here is an example:

doi:10.1175/1520-0485(1985)015<0439:TROSFF>2.0.CO;2

which is a hyperlink to

http://dx.doi.org/10.1175/1520-0485(1985)015<0439:TROSFF>2.0.CO;2

By "work" above, I mean that if you click on it, you are taken to the website the link points to, on your webbrowser.

I use Skim 1.6.5 (135) and Adobe Acrobat Reader DC 2021.007.20096 on Big Sur (macOS 11.6).

[Christiaan Hofman]

As the the display of the PDF is done by Apple's PDFKit, there is nothing we can do about this. This is the responsibility of Apple.

[Christiaan Hofman]

BTW, what you post is not a valid URL, so I don't see why it should actually work. (In fact even your http URL is not valid, as it does not escape the special characters). So there is no bug in the app. There is a bug in the PDF. Maybe Acrobat fixes the bug, but an app should not have to do that, and moreover cannot reliably do that.

[Ryo]

First of all, thank you for your message. Second, I perfectly understand the reason that you can't fix the problem. Thank you for the explanation. Third, I of course respect your decision.

Maybe Acrobat fixes the bug, but an app should not have to do that,

Now, the invalid URL included in the PDF and I posted. If you copied and pasted it onto the address box of a browser, it doesn't fail to work. I tested Safari, Firefox, Chrome, and Vivaldi. That suggests that Acrobat doesn't "fix" it. It just sends it to the browser. Why then don't the browsers reject it?

When the input is invalid, an app would try to do something maximally useful to the user. That's why those web browsers handle the invalid URL gracefully instead of rejecting it as invalid. So, while I agree that "an app should not have to do that", I think it would be nice if the app did that.

[Christiaan Hofman]

First of all, it is not a decision, it is an assessment. We cannot fix it, we never even get the URL.

And it is invalid. Yes, also browsers can indeed sometimes fix the URLs. That does not ean the URLs are valid. And in fact, when IO try to create an NSURL object from your URLs, I get nothing, so they are invalid, and the system code cannot handle them. Therefore, they can only be handled when some receiver explicitly tries to fix them. And PDFKit does not do that. Moreover, that is always a guess, because when you pass invalid data, you don't tell anyone what you were meaning (by definition), and one has to make educated guesses about what you mean.

Anyway, if you think it would be nice to make educated guesses, Apple is the one you should ask for it.