Package Details: qpdfview 0.4.16-3

Git Clone URL: https://aur.archlinux.org/qpdfview.git (read-only)
Package Base: qpdfview
Description: A tabbed PDF viewer using the poppler library.
Upstream URL: https://launchpad.net/qpdfview
Licenses: GPL2
Submitter: adamreichold
Maintainer: adamreichold
Last Packager: adamreichold
Votes: 161
Popularity: 3.777916
First Submitted: 2012-02-08 13:11
Last Updated: 2015-11-24 15:35

Dependencies (10)

Required by (0)

Sources (1)

Latest Comments

gajjanag commented on 2016-01-29 03:55

@adamreichold: thanks for the update.

After playing with the Fitz plugin based qpdfview, although I do find it useful for fast opening of large files, I have found the lack of text search quite inconvenient. Thus, I will not be creating a package for this; interested people can either use qpdfview-bzr, or create a qpdfview-fitz.

adamreichold commented on 2016-01-02 11:05

@gajjanag I updated the README file shipped with qpdfview:

> The Fitz plug-in is currently considered experimental due to the lack of a maintainer. It also lacks support for various features, e.g. meta-data, encryption, text search, text extraction, form fields and annotations.

I don't think this should go into the manual page as I don't consider the Fitz plug-in support in the first place.

gajjanag commented on 2016-01-02 04:19

@adamreichold: Thanks for the update. I will create the package and upload it soon.

This may be better for your bug tracker, but can you please give a brief description of the missing functions in fitz (e.g a BUGS section to the man page)? I have not experienced them myself, but would like to be aware of them.

adamreichold commented on 2015-12-31 00:15

@gajjanag I am glad that you find the program useful. The reason that the stable package does not enable the Fitz plug-in even if the mupdf package is installed, is that this plug-in is considered experimental as there is no maintainer dedicated to tracking the changes of the Fitz API. It also lacks various functions that the Poppler-based plug-in provides. Hence, I would suggest creating a separate AUR package (maybe qpdfview-fitz or something like that) which enables the Fitz plug-in for the stable code base.

gajjanag commented on 2015-12-30 17:14

Thanks for this fantastic package. I noticed that qpdfview-bzr has optional fitz (mupdf) plugin support, and I was interested in it for the qpdfview package since I prefer the stable release. It seems like simple modifications of this PKGBUILD by inspection of the bzr PKGBUILD can be used to obtain mupdf support here. Can you please update the PKGBUILD accordingly?

In case you are interested, I can post the modified PKGBUILD.

adamreichold commented on 2015-11-24 15:38

@lahwaacz I agree that properly tracking dependencies is important which is why I don't want to make a dependency mandatory that is actually optional. Hence I changed the package so that e.g. texlive-bin is an optional build-time dependency that will become a mandatory dependency when the main qpdfview binary links against it, but djvulibre and libspectre will stay optional as only the respective plug-ins link against them.

lahwaacz commented on 2015-11-23 21:56

@adamreichold: Quite possibly, but of course it's your call. I think that tracking all installation-time dependencies properly based on the build-time configuration is important and worth the effort and added complexity.

adamreichold commented on 2015-11-20 23:10

@lahwaacz Thank you for the suggestion. I have taken a look and even without the additional Python script, I could use the technique to e.g. add texlive-bin to the dependencies if the synctex pkg-config module exists. However, my main problem of configuring which optional (build-time) dependencies should be active is not addressed by this as far as I understand it. Also, our optional build-time dependencies on djvulibre and libspectre are also optional run-time dependencies even if enabled, as qpdfview just won't be able to load those plug-ins without them, but can nevertheless be installed and used for other formats. For now, I think another optional dependency on texlive-bin that is reflected in the dependencies automatically using the mpv-git technique is the best approximation of the real dependencies?

lahwaacz commented on 2015-11-20 15:03

@adamreichold: The mpv-git package [1] uses some tricks to automatically detect the "build-time optional" dependencies, maybe similar approach would be best even for qpdfview. No idea about the package guidelines for this though...

[1] https://aur.archlinux.org/packages/mpv-git/

adamreichold commented on 2015-11-20 07:18

Hello KlipperKyle,

this is correct as we are linking against the SyncTeX parser library from texlive-bin instead of copying its code into our source tree (which used to be the preferred method of distribution for that). But the code itself has been present in one form or the other within qpdfview for quite some time.

If you do not have texlive-bin installed, it will still use the last source tree import with all the security and maintenance implications that has. Of course, you can disable SyncTeX support if you don't need as you noted. I will probably add an optional dependency to texlive-bin as in the style of DjVu and PostScript.

Best regards, Adam.

All comments