Package Details: qpdfview-bzr 2041-1

Git Clone URL: (read-only)
Package Base: qpdfview-bzr
Description: A tabbed PDF viewer using the poppler library. (development version)
Upstream URL:
Licenses: GPL2
Conflicts: qpdfview
Submitter: adamreichold
Maintainer: adamreichold
Last Packager: adamreichold
Votes: 6
Popularity: 0.025040
First Submitted: 2012-02-07 20:39
Last Updated: 2017-04-15 11:41

Dependencies (12)

Required by (0)

Sources (1)

Latest Comments

DungeonMaster commented on 2016-12-21 19:11


I removed qpdfview-bzr, replaced the qt5 poppler with the git version in the AUR, had qpdfview-bzr build again and.. it works so *shrug* thank you for the assist.

adamreichold commented on 2016-12-21 17:59


I just tried to disable and enable "Decorate pages" using the settings dialog and everything seemed to work as expected, so I can't really tell you much expect to open a bug report on Launchpad and describe exactly what you are doing, what you expect to happen and what happens instead.

DungeonMaster commented on 2016-12-21 10:18


I'm wondering what the deal is with the program. I go to turn off settings like "Decorate Pages" and they don't work. I check settings again and "Decorate Pages" is checked again. Is there something in a build or is it something on my end?

adamreichold commented on 2016-11-03 12:18

@sleeping Please do not flag VCS packages as out-of-date due to an upstream update as makepkg will always fetch the latest trunk revision and update the package version during build.

adamreichold commented on 2016-11-02 11:24

@pmattern I do agree about the hooks and will update both packages as soon as I find the time to do so. (Of course, patches welcome in any case.)

Concerning the debug symbols, I concur with @lahwaacz that this should be enabled by each user as necessary. Of course, I would be happy to find a back trace of these recurring crashes in the project's bug tracker on Launchpad.

lahwaacz commented on 2016-10-29 09:50

Enabling debugging symbols in packages is the user's responsibility, just like fetching the latest version of VCS packages whenever necessary. Both tasks are actually equally easy, see

In any case, it doesn't make sense to enforce these as defaults in the "upstream" PKGBUILD just because you're having some problems...

pmattern commented on 2016-10-29 09:24

It would make sense to replace the install script with pacman hooks. You'd just have to drop the script and add gtk-update-icon-cache as runtime dependency. This would allow for ditching dependency hicolor-icon-theme which would be pulled by gtk-update-icon-cache.
Same goes for package qpdfview.

Also, I wonder whether it wouldn't make sense to enable debugging.
Right now both stack traces and backtrace tend to be useless one-liners when qpdfview crashes and dumps core. This is a pitty when it comes to chasing down crashes which happen sporadically but cannot be reproduced easily (like one involving opening several PDF files in parallel by clicking links in Firefox I'm seeing since a while here).
Given that one main purpose of VCS packages is testing debug symbols should actually always be enabled in these packages, IMHO, as the advantages outweigh disadvantages like higher resource usage or performance penalty in this case.

b52 commented on 2016-10-23 13:49

@adamreichold The screenshot was taken while tiling was disabled. If I however enable tiling in combination with device pixels, I get an even weirder output as shown in

Note that the quality of the rendered output is very bad without the device pixels option.

adamreichold commented on 2016-10-21 05:13

@b52 The screenshot looks like only the first tile composing the page is rendered (or if the others are rendered they are at least not displayed). Could you please check if things work correctly if tiling is disabled via the Graphics tab of the Settings dialog? If so, please file a bug on Launchpad that tiling and non-unit device pixel ratios are incompatible. Thanks!

b52 commented on 2016-10-19 20:59

Using the "device pixel option" results in weird behavior on my laptopt, as can be seen in this screenshot
Note, that it's a high dpi display.

adamreichold commented on 2016-05-06 12:31

@gothmog123 The problem is that the Fitz plug-in is broken in the current trunk revision since the outline and properties interface was changed without the Fitz plug-in being adjusted yet. Also the package dependencies are probably wrong since the headers and libraries seem to have moved to the libmupdf package. Not sure when I will find the time to fix this, patches welcome in any case...

gothmog123 commented on 2016-05-06 03:24

mupdf version doesn't compile - anyone know anything?

adamreichold commented on 2015-03-22 00:26

Hello again,

the problem with the tab navigation in the properties dock should be fixed in the latest trunk revision.

Making all docks visible definitely has no effect on the issue, but it can tell you whether your main window is using tabbed docks and has a tab bar child holding the focus even though it may be invisible. At least this is what I can reproduce during debugging: The focus being on the invisible tab bar child of the main window used by tabbed docks. In any case, the problem remains that Qt's QMainWindow controls that widget instead of qpdfview itself...

Best regards, Adam.

lahwaacz commented on 2015-03-21 20:04

Well, I don't know how "tabbed docks" look, but I think that making all docks visible has no effect on the issue. I've only noticed the "Properties" dock behaving strangely: when it is focused, pressing the "Tab" key will cycle through the table cells and the focus will never leave the dock. I'm not sure if this is an issue though...

adamreichold commented on 2015-03-20 16:26

Hello again,

after further testing, I suspect that your focus might be on an invisible dock widget tab bar that the main window creates. You can verify this by making all docks visible and check if they are tabbed (and then reproduce the situation to actually see the focus on the tab bar). If that is the case, I am not yet sure what I can do about it.

Best regards, Adam.

lahwaacz commented on 2015-03-16 17:08

Seems you are right, pressing Tab at the dead-end point returns focus back to the document widget.

Also saying that the issue occurs when switching windows was inaccurate, I've tried to make qpdfview a floating window and also could not reproduce the issue. It appears to occur only when a workspace is switched. In tiling layout there is often only one window per workspace, hence this mistake...

adamreichold commented on 2015-03-16 16:28

Hello lahwaacz,

besides preferring to track such issues using the bug tracker on Launchpad, my main problem currently is that I can't reproduce this using xfwm4 and hence I have to see if and when I find the time to set up i3 for testing.

I also don't think that this is related to changing the key bindings, but it sounds like a general focus issue w.r.t the document view widget. Did you try wether "tabbing" through the widgets until the main windows is focussed again works?

Best regards, Adam.

lahwaacz commented on 2015-03-16 09:29

One more interesting detail, at the point when page navigation with j/k keys does not work, the tab navigation with h/l keys actually works.

lahwaacz commented on 2015-03-16 09:26

I have a little but annoying problem with key bindings. I have bound the j/k keys for page down/up movement, which works only when the preview widget (or whatever it is called) is focused. The main case when the j/k keys stop working is:

1. Focus the main window, navigation with j/k works.
2. Press and release Alt modifier key, which activates keyboard navigation in the pull-down menu in the menu bar. Because Alt is the modifier key of my window manager (i3), this is often done unintentionally.
3. At this point the navigation with j/k (obviously) does not work, if Alt is pressed and released once more time it works again.
4. If instead of 3. another window is focused and then qpdfview again, navigation with j/k still does not work and the trick described in 3. does not help.

The keyboard navigation in menus is probably Qt stuff, so I don't know if anything can be done on qpdfview side. There is no option to set a modifier key for the menu navigation in the "Modifiers" tab in the settings.

Sorry for reporting the bug here, I don't feel like registering on launchpad...

zegoti commented on 2014-11-05 02:33

Hi, compilation failed, reported bug here

adamreichold commented on 2014-05-04 08:37


I changed detection of MuPDF to use "/usr/lib/libmupdf.a" again and updated the Fitz plug-in to work with MuPDF version 1.4.

Best regards, Adam.

adamreichold commented on 2014-04-06 08:06

Hello Stefan,

thanks for the hint. I changed the test to check for libmupdf-js-none.a instead. (Concerning the current master version of MuPDF itself, qpdfview will probably not work with because of API changes to which I will adapt when a new version of MuPDF is released and I find out to reliably detect the library's version for backwards compatibility.)

Best regards, Adam.

haawda commented on 2014-04-05 13:07

I think the test
if [ -f /usr/lib/libmupdf.a ]; then
local config="$config with_fitz"
is not correct. If I have my mupdf-git package installed, which no longer provides /usr/lib/libmupdf-js-none.a (and there is no obviuos way to provide it), the builds fails at the ld-step, trying to link /usr/lib/libmupdf-js-none.a

So maybe you should test in the PKGBUILD, if that file exists instead.

haawda commented on 2014-03-08 10:33

I tried revision 1479, and that works fine. Thanks for the very quick reply and fix.

adamreichold commented on 2014-03-08 08:59


there was indeed a stray dependency on OpenJPEG in the build system which form the MuPDF source code examples but which isn't actually necessary. I just committed trunk revision 1478 which removes it, please retry.

Best regards, Adam.

P.S.: I also upload a new source package adding the missing dependency on desktop-file-utils.

haawda commented on 2014-03-08 08:38

Hello, something is going wrong for me when it comes to the final linking step.

g++ -c -pipe -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -Wall -W -D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_PLUGIN -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/qt/mkspecs/linux-g++ -I. -I/usr/include/qt -I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui -I/usr/include/qt/QtCore -Imoc-fitz -o objects-fitz/moc_model.o moc-fitz/moc_model.cpp
rm -f
g++ -Wl,-O1,--sort-common,--as-needed,-z,relro -Wl,-O1 -shared -o objects-fitz/fitzmodel.o objects-fitz/moc_model.o objects-fitz/moc_fitzmodel.o -lmupdf -lmupdf-js-none -lfreetype -ljbig2dec -lopenjp2 -ljpeg -lz -lm -lQt5Widgets -lQt5Gui -lQt5Core -lGL -lpthread
/usr/bin/ld: cannot find -lopenjp2
collect2: Fehler: ld gab 1 als Ende-Status zurück
Makefile.fitz-plugin:171: recipe for target '' failed
make[1]: *** [] Error 1
make[1]: Leaving directory '/home/haawda/paketierung/not_maintained_by_me/qpdfview-bzr/src/qpdfview'
Makefile:97: recipe for target 'sub-fitz-plugin-pro-make_first-ordered' failed
make: *** [sub-fitz-plugin-pro-make_first-ordered] Error 2

For an older build (revision 1428), namcap tells me that desktop-file-utils should be a dependency, but that should be unrelated.

adamreichold commented on 2014-02-08 17:43

Hello again,

the problem with the usual way of handling optional dependencies is that IMHO they are geared towards binary distribution. In that case I would have all those dependencies as "makedepends" and the program would just fail to load the corresponding plug-in if the optional (runtime) dependency is missing. But since AUR is basically source distribution, I don't want to force people to install all these packages just for building qpdfview if they don't want the plug-ins anyway, hence the slight abuse of meta-data. If qpdfview will ever be in the community repository, this would of course change to shipping separate packages for the different plug-ins in binary form.

Regards, Adam.

lahwaacz commented on 2014-02-08 17:27

Right, I missed that... Thanks for the quick update.

I don't think there are any official guidelines on handling "optional build-time dependencies", you could ask on aur-general mailing list. Using "optdepends" suggests that qpdfview built without mupdf installed can gain extra functionality by installing mupdf. This would be confusing on a binary repo. Plus, mupdf should not be needed at all at runtime, if only the static library is required at build-time.

adamreichold commented on 2014-02-08 16:58

Hello lahwaacz,

I think the problem is in the PKGBUILD checking for the package "poppler" instead of "poppler-qt5" to decide whether to build the Poppler plug-in. I'll upload an update package...

Regards, Adam.

P.S.: All dependencies in "optdepends" except for "mupdf" are definitely runtime dependencies. MuPDF ships a static library and hence would be an optional build-time dependency for which no better key exists AFAIK.

lahwaacz commented on 2014-02-08 16:09

Hi, I got this error when poppler-qt5 was not installed. Either it should not be optional dependency after all, or the Makefile should be able to detect it. Btw, I think that optdepends is only for runtime...

( test -e Makefile.pdf-plugin || /usr/bin/qmake-qt5 /home/lahwaacz/aur/build-dirs/qpdfview-bzr/src/qpdfview/ CONFIG+=\ without_ps -o Makefile.pdf-plugin ) && make -f Makefile.pdf-plugin
Project ERROR: poppler-qt5 development package not found
Makefile:38: recipe for target 'sub-pdf-plugin-pro-make_first-ordered' failed
make: *** [sub-pdf-plugin-pro-make_first-ordered] Error 3
==> ERROR: A failure occurred in build().

adamreichold commented on 2014-01-25 08:37

The depends only optionally on Poppler, since an experimental Fitz plug-in as now also part of qpdfview but disabled by default.

adamreichold commented on 2013-08-14 18:12

Hello Stefan, you are right, I missed that additional dependency on qt5-svg, but I think it will be a run-time rather than a build-time dependency. In any case, I plan to fix this on weekend.

haawda commented on 2013-08-13 22:06

Seems to need qt5-svg as makedependency now.

adamreichold commented on 2013-08-09 19:09

Updated package to use Poppler's Qt5 frontend.

adamreichold commented on 2013-04-07 12:13

Thanks again for the advice! Changed as proposed.

haawda commented on 2013-04-07 11:39

Using "trunk" is bad for people like me, who are forced to set $SRCDEST in makepkg.conf. See fo a working solution.

adamreichold commented on 2012-03-23 16:28

Please note that this builds the latest source code from trunk. Can break any time!

adamreichold commented on 2012-03-23 16:07

Please not that this builds the latest source code from trunk. Can break any time!

haawda commented on 2012-03-18 17:20

Thank you!

adamreichold commented on 2012-03-18 16:09

Thank you for the advice. I agree that this is a more sensible way to do things. I changed the PKGBUILD and added you as a contributor.

haawda commented on 2012-03-18 15:50

You shoul introduce variables _bzrtrunk=lp:qpdfview and _bzrmod, even if you do not want to use them. This enables makepkg's revision number detection. The revision number is taken as $pkgver. This is IMHO superior to having a date as $pkgver.


haawda commented on 2012-03-18 15:48

You shoul introduce variables _bzrtrunk=lp:qpdfview and _bzrmod, even if you do not want to use them. This enables makepkg's revision number detection. The revision number is taken as $pkgver. This is IMHO superior to having a date as $pkgver.