This isn’t restricted to ‘page’: there’s a whole set of PDF fragment identifiers [0,1]. Most notably ‘zoom’, ‘view’ and named destinations, but there are others.
Interesting! And it seems like they are fairly well-supported among major browsers, with the exception of Safari [0].
Writing links by hand is rather cumbersome, though, they ought to be better exposed in PDF viewers. It certainly doesn't help adoption when the list of allowed parameter values is locked in a proprietary spec!
view=<keyword>,<position>
The arguments correspond to those found in [ISOPDF2] 12.3.2.2
"Explicit destinations". <keyword> is one of the keywords defined
in [ISOPDF2] "Table 149: Destination syntax" with appropriate
position values.
[ISOPDF2] ISO, "Document management -- Portable document format --
Part 2: PDF 2.0", ISO 32000-2:2017, 2017.
(Strictly speaking it's the 2020 revision which incorporates some errata. I don't know if the final standardized 2017 version was made freely available)
My Firefox downloads the PDF, so it does not work.
I am not sure, but it is possible that I changed the default behavior for PDF files because I didn't like the integrated PDF viewer. Nevertheless, I think this is a valid use case that should be considered when using this feature.
It's probably linking to the 'sequence number' rather than the page number. The cover is the first sequence number but doesn't have a page number. So if there was a few blank pages before the numbered pages started, it would probably be off by that many. I'll bet there are ways to mitigate that— PDF usually seems pretty good about dealing with the discrepancies between print and digital document structures.
It's one-indexed, counting that actual pages in the PDF. The nominal page numbers (as seen on the header/footer) are often different since you don't typically number title pages and the like, which is called "front matter". [0]
A quick check on iOS 17.5 gives me working links when omitting the equals symbol, like #page70 instead of #page=70
Now, this is very much against the spec [0]. At first glance, the doubled functionality of encoding parameters is irritating, there are query parameters already, so ?page=70 would seem more consistent. But then, this has been worked on for a long and it makes sense to add a whole set of functions for certain mime-types.
25 comments
[ 4.8 ms ] story [ 61.6 ms ] thread[0] https://www.rfc-editor.org/rfc/rfc8118.html#section-3
[1] https://pdfa.org/pdf-fragment-identifiers/
Writing links by hand is rather cumbersome, though, they ought to be better exposed in PDF viewers. It certainly doesn't help adoption when the list of allowed parameter values is locked in a proprietary spec!
0: https://pdfa.org/pdf-fragment-identifiers/#Browser_support_f...PDF is open since 1993, if that's the spec you mean
EDIT: If it's important that it's the actual standardized version rather than the final draft then you can get it for free here: https://www.pdfa-inc.org/product/iso-32000-2-pdf-2-0-bundle-...
(Strictly speaking it's the 2020 revision which incorporates some errata. I don't know if the final standardized 2017 version was made freely available)
I am not sure, but it is possible that I changed the default behavior for PDF files because I didn't like the integrated PDF viewer. Nevertheless, I think this is a valid use case that should be considered when using this feature.
0: https://kdp.amazon.com/en_US/help/topic/GDDYZG2C7RVF5N9J#fro...
https://developer.adobe.com/document-services/docs/assets/5b...
Now, this is very much against the spec [0]. At first glance, the doubled functionality of encoding parameters is irritating, there are query parameters already, so ?page=70 would seem more consistent. But then, this has been worked on for a long and it makes sense to add a whole set of functions for certain mime-types.
[0] https://www.rfc-editor.org/rfc/rfc8118#page-3