[announce] pdfjs-viewer: A better PDF viewer for Atom

Not the latest spec, but here you go:

12.4.2 Page Labels

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.

Source, page 374

Alright, 0-based it is! :slight_smile:

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.

1 Like

I’ve updated the spec to everything I think we’ve covered. Please let me know if I’ve missed anything.

Looks good to me, thanks.

I guess now we would need input from the authors of packages that might implement consumers.

@allefeld I ran into issues with forward synctex search using the pdfview API, as it doesn’t provide info about the page dimensions so translating top left to PDF origin doesn’t work. What do you think of adding a second optional parameter to scrollToPosition that takes an object, with the optional property origin: "TL" | "BL" for top left and bottom left of crop box respectively (omitted would default to PDF origin).

This parameter is already half planned to also allow hinting to flash the location and specify where to focus it in the view.

A couple more tweaks I want to make:

  • Change getUri to getURI to match the optional method on pane items expected by Atom (seeing as we expect the view to be a pane item).
  • Add an onDidDestroy method to the PdfView interface so that packages can remove references to observed PDFs. Without this, it’s difficult / impossible for a consumer to track which PDFs it has subscribed to (so it can cancel if it itself is disabled) without keeping them alive because of a reference to them.

I don’t understand, I thought you would be working on Atom-LaTeX, not pdfview. You can’t really do anything about pdfview without izuzak’ cooperation, can you? Could you expand on the problem and the proposed solution?

I agree with the two other changes. :slight_smile:

Not pdf-view the package, pdfview the API (this one).

For the forward sync issue, synctex still uses the top left of the TeX page as the origin. This wasn’t really an issue with backwards sync because we provide the page dimensions so it can be converted as desired, but they aren’t available when forward syncing. I couldn’t see anything in the synctex output that would help either.

The origin option would shift the recalculation to the viewer. The other alternative I can think of is adding a “get page dimensions” request.

Thanks, now I understand.

Correct if I’m wrong, but don’t get things even more complicated in case the display in the PDF viewer is rotated (which is supported by pdf.js and can be useful for the occasional landscape page). Meaning, wouldn’t we need even more different origins?

Apart from that, I feel that this origin parameter is something like an unacknowledged half-step back to the SyncTeX convention.

I tend to prefer having a “get page dimensions” request.

Btw., I received an invitation to join your organization atxmtxt, but when I visit the page I get a 404, though I am logged in.

Yup, we can go with get dimensions request. I’m thinking a Promise that resolves to the width and height. Rotation would not be considered (so the values are a property of the PDF, not the viewer).

1 Like