search

karlch / vimiv-qt

An image viewer with vim-like keybindings
https://karlch.github.io/vimiv-qt/
GNU General Public License v3.0
177 stars 15 forks source link

[Feature Request] PDF Support #525

Closed mcp292 closed 1 year ago

mcp292 commented 2 years ago

It would be nice to use one image viewer, with one set of bindings and behaviors, to view both images and PDFs. I think vimiv has a great opportunity to be this tool. Especially since mupdf lacks configurable keybindings.

jcjgraf commented 2 years ago

Hi @mcp292!

For multiple reasons I do not think that makes sense to have an image viewer (i.e. vimiv) which is also a fully blown pdf viewer. While they certainly share some aspects, like browse through image/pdf collection, zoom in and pan, there are noticeable difference like, for image you want EXIF support, basic editing, while for PDFs you want search functionality, annotation, etc.

However, if we are talking about really basic PDF support, i.e. simply display PDF as it was an image, I can see its potential. Though, I am not sure if this belongs natively into vimiv or should be provided via a plugin. As you may have noted, vimiv if very flexible and provides a powerful plugin system.

The API interface (api.add_external_handler) is used by plugins to make Vimiv capable of handling image formats, which are natively not supported (see this plugin which adds RAW support). It would be (probably) rather straight forward to display PDFs this way. You could use e.g. ImageMagick to convert PDFs to JPGS on-the-fly.

I do not know what the "indented" way is do display PDFs in QT. In PDF viewer application, which I quickly had a glimpse on, PDFs were displayed using the QWebEngineView. Vimiv-internally, images are displayed as a QPixmap. We have also made some exceptions to this, namely for SVGs and (automated) Gifs (see gui/image/ScrollableImage). If PDF support is added in a similar simple and clean way, it may be something which we could consider. More "advanced" features could still be implemented as a plugin to prevent unnecessary clutter.

I think having basic PDF support, either implemented as a standalone plugin, or with minimal changes to the core, would be nice to have. But I do not see the point of implementing advanced featured in vimivs core (but, in a plugin one can do whatever one likes :) ).

What would you personally expect from "PDF support"?

I am rather busy and not able to look into this, and unfortunately, @karlch is also super busy. But if you would like to look into this, I could assist you.

mcp292 commented 2 years ago

I agree with you. Really just looking to open up and scroll through a PDF with bindings I'm used to and can easily configure. With basic functionality, it could even be used for PDF slideshows. For anything more serious, using a dedicated PDF viewer or adding a plugin is fine.

I am unable to fit this into my workload.

dschrempf commented 2 years ago

FYI, if you want a vim-like PDF viewer, you could try Zathura.

mcp292 commented 2 years ago

Good to know, thank you!

mcp292 commented 2 years ago

Are the bindings configurable?

dschrempf commented 2 years ago

Yes. I think it is best if you check the documentation https://pwmt.org/projects/zathura/ or man zathurarc.

mcp292 commented 2 years ago

Will check it out.

ghost commented 1 year ago

Also checkout sioyek: https://github.com/ahrm/sioyek

karlch commented 1 year ago

Sorry for being super late to the party! And thanks to everyone who has participated in the discussion :blush:

A definite +1 for zathura from me, love using it!

I had a bit of thinking about this, and honestly don't think pdfs and images are similar enough to work on this in mainline vimiv. For example, how would we deal with various pages? Concatenate and have a super high image - looks horribly broken. And everything else is basically writing pdf support (with pages, which an image just doesn't have).

If someone comes up with a simple plugin that for example displays an image preview of the first pdf page, I would be more than happy to discuss / link / maybe even merge into the plugin landscape upstream. But I don't think working on this directly is the way to go, especially given our limited time resources, sorry!