Description: This is a simple program for viewing PDF files. There is also a library providing a PdfView widget which can be easily embedded in other programs.
The reason for writing this program is to have a lightweight Qt-only PDF viewer with the features that I want. As my time is limited, I probably won't have time to implement any feature requests for this program. Of course you should still post the requests, but they will likely end up in the TODO list. If you want to see additional features, sending patches will dramatically increase the chances of seeing the features implemented. Any developers are welcome to join this project.
Features: "continuous" view mode (other view modes do not exist yet) magnifying glass when clicking with the left mouse button on the page reload PDF file when it is changed on disk by another program links in "Table of Contents" are clickable links in PDF file are clickable search string in document interface without menu bar (interface with menu bar can be obtained by changing the option in the configuration dialog and then restarting the program) presentation mode it is possible to modify the style of the buttons in the tool bar by clicking with the right mouse button on the toolbar shortcut editing dialog bookmarks mechanism remember page positions and zoom factor per file throughout sessions select image or text in a rectangular area text selection support for forward search and inverse search using synctex (it is also possible to compile this app+lib without synctex support) printing support for PDF forms
Note that the user interface can be completely controlled using the keyboard (except for the magnifying glass, selection and links). When no menu bar is shown, the items in the tool bar can be triggered using Alt + their accelerator. The "Open File" dialog can be accessed using the standard "Open" shortcut (in an English system this is usually "Ctrl+O").Last changelog:
version 0.7 - add support for PDF forms - move mouse tool changing actions to the library - make sure the library is installed in /usr/lib64 when appropriate - add option to print multiple pages on one page
Dear Glad,
thank you for your great work on pdfview. I especially appreciate that the program is very lightweight and with clean source code. I started my own fork, tuned to my specific personal needs:
https://github.com/amkhlv/pdfviewer
Please keep working on pdfview, I think this is the best available PDF viewer.
Andrei
Hi, please add link PKGBUILD https://aur.archlinux.org/packages/pdfviewer/
for Archlinux. thanks.
I can't print because it surrounds the filename to send to lp with literal quotes. fix with patch....?
Is it ever going to be possible to have persistant annotations like the latest Okular, that is, saved annotations which are readable by the recipients irrespective of their OSes?
I don't like the tone of this question. Did you ever pay me for developing this software? Did you ever contribute a working, maintainable patch that doesn't break anything? No, you didn't. So accept the fact that I don't write the software for you, I write it for me. Be happy that you can use it without contributing anything. My free time is limited, so the features will take long to be implemented, unless you or someone else starts contributing. That's the whole point of open source software after all: the developer publishes the code so that others can contribute. Up to now that didn't happen, so tell me: why would I continue to publish this program on this site?
There are many things to say against your screech, but I'll just say these:
1. The tone of my question was COMPLETELY SINCERE AND NEUTRAL one. I was just curious if it's in your to do list or not, if it's achievable or not. It only needs a mean-sprited effort to mis-interpret it something (even) like that: "Hey developer, for god's sake, when will you implement this feature?"
2. I will never ever use your app.
"Is it ever going to be possible" sounds to me like "I am waiting for ages for this feature, so when is it finally going to be implemented?" A better phrasing would have been: "Are there any plans to implement persistent annotations?" or "Is it going to be possible in the future to have persistent annotations?"
If there is anything else wrong in my remark, I would be happy to learn it.
This has nothing to do with this project.
It is caused by the poppler-qt4 Class that does not support built in Thumbnails.
A bug has been submitted to correct this.
In poppler/qt4/src/poppler-page.cc in function Page::thumbnail()
the following code must be added
[starting with the 'else']:
if (r)
{
..
}
else
{
ret=renderToImage();
w=50;
h=75;
if (ret.width() > ret.height())
{
h=50;
w=75;
}
ret = ret.scaled(w,h,Qt::IgnoreAspectRatio);
}
Your usage of the attributes 'DestinationName' and 'Destination' are incorrect.
The String returned from 'Destination' is the result of LinkDestination.toString() that was created when document()->toc() is called in 'fillInfo'. This is an Array of 10 values, where by the array[1] and array[5] are needed to create the PageNumber.
Why your code in creating Poppler::LinkDestination fails I cannot say, but when
ld = data.doc->doc->findDest( data.namedDest );
is called, no result is found and it returns pageNumber 0.
This means that when the toc is clicked in your demo application, it will allways move to page 1.
Here is a small diff that will correct this:
app_src_tocdoc.patch:
diff -rupN original/tocdock.cpp modified/tocdock.cpp
--- original/tocdock.cpp 2012-06-06 20:26:57.000000000 +0200
+++ modified/tocdock.cpp 2012-07-11 04:58:34.359280108 +0200
@@ -32,10 +32,12 @@ static void fillToc(Poppler::Document *d
// for some unknown reason e.attribute("Destination") does not exist while Okular successfully uses it; so we cannot use Poppler::LinkDestination(e.attribute(QString::fromLatin1("Destination"))).pageNumber() and must use the following
// const int pageNumber = doc->linkDestination(e.attribute(QString::fromLatin1("DestinationName")))->pageNumber();
- Poppler::LinkDestination *dest = doc->linkDestination(e.attribute(QString::fromLatin1("DestinationName")));
- const double pageNumber = dest->pageNumber() + dest->top();
- delete dest;
-
+ // Poppler::LinkDestination *dest = doc->linkDestination(e.attribute(QString::fromLatin1("DestinationName")));
+ // const double pageNumber = dest->pageNumber() + dest->top();
+ // delete dest;
+ // LinkDestination.toString(): 0=kind;1=PageNr as int;2=left;3=bottom;4=right;5=top;6=zoom;7=changeLeft;8=changeTop;9=changeZoom
+ QStringList sa_LinkDestination_Values=e.attribute(QString::fromLatin1("Destination")).split(";");
+ const double pageNumber = sa_LinkDestination_Values[1].toDouble()+sa_LinkDestination_Values[5].toDouble();
if (!parentItem) {
newitem = new QTreeWidgetItem(tree, newitem);
} else {
---end diff---
after writing this I will also submit a diff to the poppler project to change the demo qt4 application so that it to will reacte correctly when a toc is clicked.
I will quote this site, since it is your TocDock::goToPage slot logic that is missing in their 'toc.cpp' implementation.
It would be nice if both demos would be updated so that the toc logic works correctly.
Today any pdf-viewer where the toc does not work is in my opinion useless.
Had the poppler project implemented in there demo, what you have allready done and docmented the return value of "Destination" properly (or at least showed the usage of it) - then I would not have had to spent hours searching for the cause of this.
[ 99%] Building CXX object app/src/CMakeFiles/pdfviewer.dir/qrc_pdfviewer.cxx.o
Linking CXX executable pdfviewer
/usr/bin/ld: CMakeFiles/pdfviewer.dir/__/__/lib/src/synctex/synctex_parser.c.o: undefined reference to symbol 'gzclose'
/usr/bin/ld: note: 'gzclose' is defined in DSO /lib/libz.so.1 so try adding it to the linker command line
/lib/libz.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[2]: *** [app/src/pdfviewer] Error 1
make[1]: *** [app/src/CMakeFiles/pdfviewer.dir/all] Error 2
make: *** [all] Error 2
I can't compile version 0.4.
Error:
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/pdfviewer.dir/synctex/synctex_parser.c.o: undefined reference to symbol 'gzclose'
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: note: 'gzclose' is defined in DSO /lib64/libz.so.1 so try adding it to the linker command line
/lib64/libz.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
All your problems should be solved in version 0.6, except for the installation in lib64. Not all platforms have a lib64 directory (e.g. Ubuntu). You have to set the value of LIB_INSTALL_DIR to /usr/lib64 in the file lib/cmake/modules/PdfViewLibConfig.cmake (if you use cmake) or in lib/qmake/pdfviewlibconfig.pri (if you use qmake) before compiling.
Thanks! Finally built it.
Using 'qmake LIB_INSTALL_DIR=%{_libdir}'.
Not tested yet with cmake.
One note: please remove 20x20 icon. This size is incorrect for hicolor-icon-theme.
Prooflink: http://cgit.freedesktop.org/xdg/default-icon-theme/tree/Makefile.in
Russian translation isn't compiled and installed.
I tryed to add 'ru' to translations.pri
LANGUAGES = ru fr # list all the languages here
This doesn't help.
Try adding ru to TRANSLATIONS in version 0.4 and run "make ts" in the build directory. This should now produce a file "pdfviewer_ru.ts" in the translations directory.
The file pdfviewer_ru.ts should of course be translated by someone, maybe you? ;) You can take inspiration from qtpdfview_ru.ts which contains the translation of the original PDF viewer demo shipped with Poppler.
Glad,
"reload PDF file when it is changed on disk by another program"
Does that mean that it can be used with LyX? With Okular we enter in LyX Pref./Output/PDF command this:
okular --unique "file:$$o#src:$$n $$t"
(http://wiki.lyx.org/LyX/SyncTeX#toc6)
Any idea about how to setup pdfviewer with LyX if possible?
Ratings & Comments
51 Comments
archive holds something called viewMaths4. not pdfview.
Dear Glad, thank you for your great work on pdfview. I especially appreciate that the program is very lightweight and with clean source code. I started my own fork, tuned to my specific personal needs: https://github.com/amkhlv/pdfviewer Please keep working on pdfview, I think this is the best available PDF viewer. Andrei
Hi, please add link PKGBUILD https://aur.archlinux.org/packages/pdfviewer/ for Archlinux. thanks. I can't print because it surrounds the filename to send to lp with literal quotes. fix with patch....?
Is it ever going to be possible to have persistant annotations like the latest Okular, that is, saved annotations which are readable by the recipients irrespective of their OSes?
I don't like the tone of this question. Did you ever pay me for developing this software? Did you ever contribute a working, maintainable patch that doesn't break anything? No, you didn't. So accept the fact that I don't write the software for you, I write it for me. Be happy that you can use it without contributing anything. My free time is limited, so the features will take long to be implemented, unless you or someone else starts contributing. That's the whole point of open source software after all: the developer publishes the code so that others can contribute. Up to now that didn't happen, so tell me: why would I continue to publish this program on this site?
There are many things to say against your screech, but I'll just say these: 1. The tone of my question was COMPLETELY SINCERE AND NEUTRAL one. I was just curious if it's in your to do list or not, if it's achievable or not. It only needs a mean-sprited effort to mis-interpret it something (even) like that: "Hey developer, for god's sake, when will you implement this feature?" 2. I will never ever use your app.
"Is it ever going to be possible" sounds to me like "I am waiting for ages for this feature, so when is it finally going to be implemented?" A better phrasing would have been: "Are there any plans to implement persistent annotations?" or "Is it going to be possible in the future to have persistent annotations?" If there is anything else wrong in my remark, I would be happy to learn it.
Thumbnails aren't displayed in the thumbnails panel.
This has nothing to do with this project. It is caused by the poppler-qt4 Class that does not support built in Thumbnails. A bug has been submitted to correct this. In poppler/qt4/src/poppler-page.cc in function Page::thumbnail() the following code must be added [starting with the 'else']: if (r) { .. } else { ret=renderToImage(); w=50; h=75; if (ret.width() > ret.height()) { h=50; w=75; } ret = ret.scaled(w,h,Qt::IgnoreAspectRatio); }
Your usage of the attributes 'DestinationName' and 'Destination' are incorrect. The String returned from 'Destination' is the result of LinkDestination.toString() that was created when document()->toc() is called in 'fillInfo'. This is an Array of 10 values, where by the array[1] and array[5] are needed to create the PageNumber. Why your code in creating Poppler::LinkDestination fails I cannot say, but when ld = data.doc->doc->findDest( data.namedDest ); is called, no result is found and it returns pageNumber 0. This means that when the toc is clicked in your demo application, it will allways move to page 1. Here is a small diff that will correct this: app_src_tocdoc.patch: diff -rupN original/tocdock.cpp modified/tocdock.cpp --- original/tocdock.cpp 2012-06-06 20:26:57.000000000 +0200 +++ modified/tocdock.cpp 2012-07-11 04:58:34.359280108 +0200 @@ -32,10 +32,12 @@ static void fillToc(Poppler::Document *d // for some unknown reason e.attribute("Destination") does not exist while Okular successfully uses it; so we cannot use Poppler::LinkDestination(e.attribute(QString::fromLatin1("Destination"))).pageNumber() and must use the following // const int pageNumber = doc->linkDestination(e.attribute(QString::fromLatin1("DestinationName")))->pageNumber(); - Poppler::LinkDestination *dest = doc->linkDestination(e.attribute(QString::fromLatin1("DestinationName"))); - const double pageNumber = dest->pageNumber() + dest->top(); - delete dest; - + // Poppler::LinkDestination *dest = doc->linkDestination(e.attribute(QString::fromLatin1("DestinationName"))); + // const double pageNumber = dest->pageNumber() + dest->top(); + // delete dest; + // LinkDestination.toString(): 0=kind;1=PageNr as int;2=left;3=bottom;4=right;5=top;6=zoom;7=changeLeft;8=changeTop;9=changeZoom + QStringList sa_LinkDestination_Values=e.attribute(QString::fromLatin1("Destination")).split(";"); + const double pageNumber = sa_LinkDestination_Values[1].toDouble()+sa_LinkDestination_Values[5].toDouble(); if (!parentItem) { newitem = new QTreeWidgetItem(tree, newitem); } else { ---end diff--- after writing this I will also submit a diff to the poppler project to change the demo qt4 application so that it to will reacte correctly when a toc is clicked. I will quote this site, since it is your TocDock::goToPage slot logic that is missing in their 'toc.cpp' implementation. It would be nice if both demos would be updated so that the toc logic works correctly. Today any pdf-viewer where the toc does not work is in my opinion useless. Had the poppler project implemented in there demo, what you have allready done and docmented the return value of "Destination" properly (or at least showed the usage of it) - then I would not have had to spent hours searching for the cause of this.
[ 99%] Building CXX object app/src/CMakeFiles/pdfviewer.dir/qrc_pdfviewer.cxx.o Linking CXX executable pdfviewer /usr/bin/ld: CMakeFiles/pdfviewer.dir/__/__/lib/src/synctex/synctex_parser.c.o: undefined reference to symbol 'gzclose' /usr/bin/ld: note: 'gzclose' is defined in DSO /lib/libz.so.1 so try adding it to the linker command line /lib/libz.so.1: could not read symbols: Invalid operation collect2: ld returned 1 exit status make[2]: *** [app/src/pdfviewer] Error 1 make[1]: *** [app/src/CMakeFiles/pdfviewer.dir/all] Error 2 make: *** [all] Error 2
Try compiling using qmake. Alternatively add -lz to target_link_libraries in lib/src/CMakeLists.txt and be so kind to report if this works.
The problem should be solved in version 0.6 (also when using cmake).
I can't compile version 0.4. Error: /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/pdfviewer.dir/synctex/synctex_parser.c.o: undefined reference to symbol 'gzclose' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: note: 'gzclose' is defined in DSO /lib64/libz.so.1 so try adding it to the linker command line /lib64/libz.so.1: could not read symbols: Invalid operation collect2: ld returned 1 exit status
Try version 0.5.
The same error. I modified app/src/CMakeLists.txt:110 target_link_libraries(pdfviewer ${QT_LIBRARIES} ${POPPLER_QT4_LIBRARIES} -lz) Then it compiled, but failed install. -- Installing: /home/abuild/rpmbuild/BUILDROOT/pdfviewer-0.5.1-0.x86_64/usr/bin/pdfviewer CMake Error at app/translations/src/cmake_install.cmake:38 (FILE): file INSTALL cannot find "/home/abuild/rpmbuild/BUILD/pdfviewer-0.5.1/build/app/translations/src/CMakeFiles/CMakeRelink.dir/pdfviewer". Call Stack (most recent call first): app/translations/cmake_install.cmake:37 (INCLUDE) app/cmake_install.cmake:38 (INCLUDE) cmake_install.cmake:37 (INCLUDE) make: *** [install] Error 1 Built with qmake successfully though.
Libraries are installed in lib. Should be lib64 in x86_64 systems.
Wrong place for pdfview.h. Should be include instead of includes.
All your problems should be solved in version 0.6, except for the installation in lib64. Not all platforms have a lib64 directory (e.g. Ubuntu). You have to set the value of LIB_INSTALL_DIR to /usr/lib64 in the file lib/cmake/modules/PdfViewLibConfig.cmake (if you use cmake) or in lib/qmake/pdfviewlibconfig.pri (if you use qmake) before compiling.
Thanks! Finally built it. Using 'qmake LIB_INSTALL_DIR=%{_libdir}'. Not tested yet with cmake. One note: please remove 20x20 icon. This size is incorrect for hicolor-icon-theme. Prooflink: http://cgit.freedesktop.org/xdg/default-icon-theme/tree/Makefile.in
Russian translation isn't compiled and installed. I tryed to add 'ru' to translations.pri LANGUAGES = ru fr # list all the languages here This doesn't help.
Try adding ru to TRANSLATIONS in version 0.4 and run "make ts" in the build directory. This should now produce a file "pdfviewer_ru.ts" in the translations directory.
The file pdfviewer_ru.ts should of course be translated by someone, maybe you? ;) You can take inspiration from qtpdfview_ru.ts which contains the translation of the original PDF viewer demo shipped with Poppler.
Glad, "reload PDF file when it is changed on disk by another program" Does that mean that it can be used with LyX? With Okular we enter in LyX Pref./Output/PDF command this: okular --unique "file:$$o#src:$$n $$t" (http://wiki.lyx.org/LyX/SyncTeX#toc6) Any idea about how to setup pdfviewer with LyX if possible?
Support for synctex is not implemented yet. It is planned, but there is no guarantee that it will be implemented soon, so patches are welcome.