Each page in a PDF document shall be identified by an integer page index that expresses the page’s relative position within the document. In addition, a document may optionally define page labels (PDF 1.3) to identify each page visually on the screen or in print. Page labels and page indices need not coincide: the indices shall be fixed, running consecutively through the document starting from 0 for the first page, but the labels may be specified in any way that is appropriate for the particular document.
I considered adding an open method alongside observePdfViews, but it quickly turned into an atom.workspace.open clone. I agree, we should specify that the ‘normal’ way to open files is the expected way here too. We can return to this later if more complicated methods are needed.
Yeah, that’s weird. First, PDF.js disables the context menu and prevents the event propagation. But I think the actual issue is onauxclick, which apparently handles all non-primary buttons instead of onclick. If you subscribe to both it should capture all clicks. As far as this spec is concerned though, it’s exposed as the single “on did click” event.
That’s possible, but less likely. For PDF.js at least, the only case I know of where this might happen is panning, and that doesn’t trigger the click event unless it doesn’t move anything.
It’s also allowed for the viewer to not report events if it feels they are only meant for the viewer itself. If the user finds the viewer doesn’t respond to the events they want, they can find a different viewer or configure the consumer differently.
Maybe a flag indicating if the viewer intends to send only the generic event could be useful for the client, but I’d rather wait until we need this than design it now. Adding this flag would be backwards compatible and we’d probably have a better idea of how useful things are.
The various conversion methods are here, and they’ve been stable for a few years at least.