You can deeplink to a specific PDF page | Hacker News Reader

You can deeplink to a specific PDF page

technicalwriting.dev

89 pointsmarban23 comments

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.

[0] https://www.rfc-editor.org/rfc/rfc8118.html#section-3

[1] https://pdfa.org/pdf-fragment-identifiers/

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.

0: https://pdfa.org/pdf-fragment-identifiers/#Browser_support_f...

> a proprietary spec

PDF is open since 1993, if that's the spec you mean

Is there a freely available copy of the document referenced earlier? I couldn’t find one with some brief googling.

Straight from Adobe's website: https://developer.adobe.com/document-services/docs/assets/5b...

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)

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.

[0] https://www.rfc-editor.org/rfc/rfc8118#page-3

Similarly, in Obsidian, you can embed specific PDF pages using the following syntax: ![[foo.pdf#page=666]]

See the standard: ISO/DIS 32000-2 (Annex O: “Fragment identifiers”, page 942)

https://developer.adobe.com/document-services/docs/assets/5b...

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 a shame that Firefox doesn't pass on the parameter(s) to your external PDF viewer.

In chrome I can even link to https://labs.pdfa.org/FragmentTest.pdf#Back%20to%20lower%20l... but can't see where spec allows for that.

It’s not part of the spec, apparently, but Adobe discusses it at https://helpx.adobe.com/acrobat/kb/link-html-pdf-page-acroba....

Looks like the pages are zero indexed? That sample link with page=70 got me to page 69 (in both Firefox and Chrome on Linux)

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]

0: https://kdp.amazon.com/en_US/help/topic/GDDYZG2C7RVF5N9J#fro...

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.

No. it's page 70 in the PDF. But the title page is visibly numbered "i" and only the following page is numbered "1". That offsets everything by one.

Ah, i kinda expected the UI (https://i.vgy.me/beZtWa.png) to show the actual PDF page number, never noticed the "i" thing. Thanks.

Chrome on Android does not work either.

Unsurprisingly, I find also unsupported on Firefox for iOS.

well... firefox on ios is still safari

*Webkit

iOS doesn't allow 3rd parties to run language interpreters, all browsers on it are just reskinned Safari.

Reply on news.ycombinator.com