Generic PDF viewer

[Aerijo]

Hey @ashthespy, @allefeld and I have been drawing up a PDF viewer service intended to make it possible to use any viewer that implements the service.

It's currently more of a final draft, and not implemented by anything, but we were looking for input from a potential consumer on how likely you are to use it, what changes you might need, etc.

The main goal of the service is to abstract away the viewer. This

• lets users pick their preferred viewer, so they get a consistent experience
• decouples things in case a project stops being maintained
• makes it so packages don't need to bundle their own viewers

Part of the goal is also to maintain existing functionality. The biggest use case we know of for this service is SyncTeX. From my experience of this package, the only thing the service can't do yet is flash the area being scrolled to in a forward search (see the TODO on the scroll method though). I also know some SyncTeX implementations use the surrounding words as context for reverse searches, which is not possible with the current spec.

If you are interested, we can work on implementing the service in the viewers, and then I or someone could make a PR here to hook into it.

[ashthespy]

I started working on something similar as well as part of #152 - by splitting out the viewer into its own package. But never got around to publishing it..

While the initial idea behind packaging everything was @James-Yu's call, I don't mind incorporating an external PDFjs based viewer, and bundling it.

That being said, what's the consensus on which to use? atom-pdf-view-plus or atom-pdfjs-viewer? I am bit short on time these days, so will play around in my spare time to figure out how to utilise the providers - but no promises on ETA.

[allefeld]

I'm sure @Aerijo is partial for his package, as I am for mine. :)

But @ashthespy the point of the proposal is that you as authors of a consuming package don't have to decide, you leave it to the user.

I just published a package that creates PDFs via Pandoc, and in the documentation I recommend my pdfjs-viewer, but mention that pdf-view-plus and pdf-view work as well. All of them working needed some fiddling around, that would not be necessary anymore with the service.

[ashthespy]

@allefeld While choice is great, wouldn't it be better that we focus efforts towards one viewer to rule them all?
I'd like to avoid similar situations with the latex-grammar/builder packages, and streamline and achieve similar maturity as VSCode's LaTeX-Workshop

[Aerijo]

@ashthespy Given it’s size I would have called pdf-view the one viewer to rule them all, but it’s development stagnated. With a service, it leaves room for anyone to come in and make a replacement (by forking or from scratch).

[allefeld]

@ashthespy, I understand and you may be right. Regarding download numbers, pdf-view is far ahead and therefore the de facto ruler. It's just not a very good package.

I'm a Debian user, where packages have dependencies, and often one package's dependencies can be fulfilled by several other packages. So though Atom unfortunately doesn't have dependencies between packages, I see the appeal of choice and a common interface, which is why I worked with @Aerijo on the service specification.

But of course this only makes sense if there are consumers, so in the end the decision actually rests with you.

In any case, I am interested in having my package be as good as possible, and I am open to suggestions and contributions. But I'm sure the same holds for @Aerijo.

[ashthespy]

@Aerijo @allefeld I currently don't have much time to invest in this package, and should be spending more time writing my papers ;-) But, if either of you are open to writing up a PR as how this service will integrate, will be happy to review and add it.

[allefeld]

@ashthespy, I'm afraid I won't be able to do that. I'm almost exclusively writing Markdown these days (translated into LaTeX and then PDF by Pandoc), using my shiny new Pandoc/PDF package.

[Aerijo]

@ashthespy That’s fine, I’ll give it a go after implementing it in my viewer.

[Bendodroid]

@ashthespy Given it’s size I would have called pdf-view the one viewer to rule them all, but it’s development stagnated. With a service, it leaves room for anyone to come in and make a replacement (by forking or from scratch).

I agree, it works very nicely with SyncTex with the latex plugin I used before atom-latex. I'm not sure there is need to reimplement everything. Maybe just fork pdf-view. Or contribute upstream.