Okular – Universal document viewer
okular.kde.org
okular.kde.org
apt install mupdf on Debian, your distribution may vary.
Edit: I tried installing MuPDF, and it doesn't hold a candle to Okular, which is far easier to use in practically every way, and which is far more capable. MuPDF is fast at rendering pages, but is extremely limited (e.g. it can't even scroll or display pages side by side).
MuPDF is very noticeably faster than Okular, so I use MuPDF for most cases when I just want to read quickly a PDF file or search through it. Therefore MuPDF is the default application for opening a PDF file, because it opens the file instantaneously, saving me a lot of time when I browse through many PDF files.
Whenever I find a PDF file with which MuPDF has difficulties or I need a feature available only in Okular, I use Okular.
$ zathura Books/nonfiction/English/Douglas_Murray/Douglas_Murray-The_War_on_the_West-2022-HarperCollins-English.epub
error: Could not determine file type.
This is the version currently on Debian/Sid, with all packages installed (zathura, zathura-ps, zathura-djvu, zathura-cb). I also noticed zathura renders PDF differently (and noticeably slower) compared to mupdf. It does not use mupdf as a backend, instead depending on libpoppler:
Depends: libc6 (>= 2.4), libgirara-gtk3-3 (>= 0.2.7), libglib2.0-0 (>= 2.16.0), libpoppler-glib8 (>= 0.18.0), zathura-abi-4
Which version of Zathura do you have installed?
[edit]
Checking around I noticed that Zathura can use mupdf as a backend but this is not enabled in the build currently on Debian/Sid. It is available in e.g. Arch [1] but Debian does not package this part. I'll build it myself and give it a try.
Depends: kinit, kio, libc6 (>= 2.33), libfreetype6 (>= 2.2.1), libjpeg62-turbo (>= 1.3.1), libkf5activities5 (>= 5.68.0~), libkf5archive5 (>= 5.68.0~), libkf5bookmarks5 (>= 5.68.0~), libkf5codecs5 (>= 4.96.0), libkf5completion5 (>= 5.68.0~), libkf5configcore5 (>= 5.68.0~), libkf5configgui5 (>= 5.68.0~), libkf5configwidgets5 (>= 5.83.0), libkf5coreaddons5 (>= 5.68.0~), libkf5crash5 (>= 5.68.0~), libkf5i18n5 (>= 5.68.0~), libkf5itemviews5 (>= 4.96.0), libkf5jobwidgets5 (>= 4.96.0), libkf5kexiv2-15.0.0 (>= 5.68.0~), libkf5kiocore5 (>= 5.69.0), libkf5kiowidgets5 (>= 5.69.0), libkf5parts5 (>= 5.68.0~), libkf5pty5 (>= 5.68.0~), libkf5purpose-bin, libkf5purpose5 (>= 5.68.0~), libkf5service-bin, libkf5service5 (>= 4.96.0), libkf5textwidgets5 (>= 5.68.0~), libkf5wallet-bin, libkf5wallet5 (>= 5.68.0~), libkf5widgetsaddons5 (>= 5.77.0), libkf5windowsystem5 (>= 5.68.0~), libkf5xmlgui5 (>= 5.80.0), libokular5core9 (= 4:21.12.3-2), libphonon4qt5-4 (>= 4:4.8.0), libpoppler-qt5-1 (>= 21.11.0), libqmobipocket2 (>= 4:17.08~), libqt5core5a (>= 5.15.1), libqt5dbus5 (>= 5.14.1), libqt5gui5 (>= 5.14.1) | libqt5gui5-gles (>= 5.14.1), libqt5printsupport5 (>= 5.13.0~), libqt5texttospeech5 (>= 5.12.0~), libqt5widgets5 (>= 5.15.1), libqt5xml5 (>= 5.13.0~), libspectre1 (>= 0.2.3), libstdc++6 (>= 11), phonon4qt5, zlib1g (>= 1:1.1.4)
Compare this to mupdf:
Depends: freeglut3 (>= 2.8.1), libc6 (>= 2.33), libfreetype6 (>= 2.6), libgl1, libgumbo1 (>= 0.9.2), libharfbuzz0b (>= 0.9.11), libjbig2dec0 (>= 0.19), libjpeg62-turbo (>= 1.3.1), libmujs1 (>= 1.0.7), libopenjp2-7 (>= 2.0.0), libssl1.1 (>= 1.1.0), libx11-6, libxext6, zlib1g (>= 1:1.2.0)
If you're already using KDE Okular is a natural choice. If you're not there are better alternatives, e.g. Atril for Mate-users, Evince for Gnome users and, yes, mupdf for those who do not use any "desktop environment". Those who use older hardware (like me) appreciate the nimbleness of tools like mupdf. It also fits in perfectly when using a tiling window manager (Xmonad etc) as it does not have any UI elements getting in the way, only showing what you're actually interested in. It supports (according to the man page) PDF, XPS, EPUB, XHTML, CBZ, and various image formats such as PNG, JPEG, GIF, and TIFF.
This is akin to vi vs VS-Code, to each his own I'd say.
I did the AppImage thing for a while, but it was too difficult to keep up to date without the developers prodiving that themselves.
Side Note: Flatpak is actually pretty nice, the lengthas I went to avoid it were pretty unreasonable in retrospect.
There is no wrong mouse button.
I don't use mice (the cat tends to eat them) but touchpads (which he only tends to sit on) without any buttons. For me the "right" button means two fingers, hence "right".
I use logseq's integrated pdf reader for these scenarios - while it can be sluggish at times, it is helpful to be able to read, outline, highlight & crosslink things in the same application.
I haven’t used Windows for at least half a decade, but I remember using Sumatra PDF, and thought that was the best pdf viewer for windows.
It's free, extremely light -weight and feature rich. And reads a lot formats- epub, mobi, cbr, you name it.
You should definitely try Sumatra PDF.
SumatraPDF supports basic annotations as of version 3.3 https://www.sumatrapdfreader.org/docs/Editing-annotations
In fact in the second case, I recommended the app, and my friend rejected because he felt the touchpad scrolling was off.
https://pwmt.org/projects/zathura/
The world of readers seems to be stuck in a rather uncomfortable local optimum, with applications which strive to be only readers (e.g., Adobe Acropat, xpdf), some of those single-format, some multi, and those which are either in themselves or within a larger ecosystem part of a document / library management system. None seems to have emerged as either dominant or satisfactory.
I'm including e-book reader hardware and software in this classification. Arguably "web browsers" as well, which seem to be hell-bent on becoming surveillance / application-delivery / commerce platforms, rather than being document-oriented.
I don't have very high requirements for PDF viewers. It does the job just fine anyway :)
It certainly seems, though, that Macs are an afterthought for this project: the binary is unsigned, the last successful build is over six months old, and the UI isn't anti-aliased on Retina.
The primary target for this is KDE Plasma, so yes, they probably are.
``` set default-bg "#2E3440"
## Start in dark mode by default set recolor true
## Nord colors for dark more set recolor-darkcolor "#D8DEE9" set recolor-lightcolor "#2E3440" ```
Ironic that it's failing while attempting to acquire a license....
I try to get as many applications from there as possible. Firefox is there. Blender even has both the latest greatest and the LTS available.
Just yesterday I tried it with msys64, but after pdf-tools-install works just fine, opening a PDF file just gives me "unable to write to temporary file".
For whatever reason, Evince didn't work right for me on the first try under KDE, so I switched to okular, and never looked back. KDE was preloaded on my laptop, and it's tolerable.
I used to use gnome stuff under minimalist window managers, but that's getting harder and harder on laptops, due to strange hardware integrations with desktop environments.
Sometimes I think the year of the linux desktop was 2003. High dpi displays just worked. So did networking stuff and suspend resume.
Anyway, I'll end my rant by pouring one out (each) for xpdf and evince.
I typed "fast linux pdf viewer" into a search engine and quickly landed at Okular, which has a setting to prerender everything and keep it in memory. It flies!
MuPDF is by far the fastest, much faster than Okular or Evince, both at rendering pages and at navigation through the document (also the keyboard-shortcut-based user interface of MuPDF is much faster than the more typical GUI of the other PDF readers).
MuPDF has various limitations and sometimes I find certain PDF files that it cannot render, so it cannot be used as the only PDF viewer.
Nevertheless, using MuPDF to handle the common cases of quickly opening, searching and reading PDF files, together with a fall-back more complete PDF reader, e.g. Okular, seems the best option on Linux.
Now, I'd like to see double (facing) pages. And it seems MuPDF can't do that. So I'm stuck with Okular, which is sad, as it's the only reason for me to have QT installed...
You can reposition the box or resize it if text gets truncated or some of the original PDF is obscured.
It is impressively fast. It's pretty much rendered the default PDF viewer on my Ubuntu obsolete, because SumatraPDF is minimalist and perfect on its key features: browsing PDFs fast, selecting text and finding text.
Had no idea it was also for Windows, I might have to start recommending it to friends/family instead of Sumatra.
so far, the best open source alternative (it's not perfect) is Inkscape with the new multi-page feature. You can import/export multi-page PDF documents.
Also, why do I still need kaccounts-integration dependency package if I am not using KDE? Is there a reason why it is needed? Anybody know?
It's a better bet to use your package manager for effectively a graph of dependencies ideally limited to a finite depth for brevity.
Looks like okular <- purpose <- kaccounts stuff also
okular <- kio <- half the kde universe
Regarding purpose
This framework offers the possibility to create integrate services and actions on any application without having to implement them specifically. Purpose will offer them mechanisms to list the different alternatives to execute given the requested action type and will facilitate components so that all the plugins can receive all the information they need.
Sounds sort of like android intents?
The situation remains that basically the first KDE app if you have nothing KDE/QT is 2GB the second and subsequent are 10MB. Honestly with storage costing almost nothing per GB and very limited developer resources this isn't a terrible design. Spending something you don't have in order to save people are resource none of them are going to care about doesn't seem like a great investment.
This makes sense. Completely forgot about this part. What an idiot I am.
> The situation remains that basically the first KDE app if you have nothing KDE/QT is 2GB the second and subsequent are 10MB. Honestly with storage costing almost nothing per GB and very limited developer resources this isn't a terrible design. Spending something you don't have in order to save people are resource none of them are going to care about doesn't seem like a great investment.
It does makes sense. In a way. But this isn't about space though. To me being in a rolling distro, it just adds weights for package breakage. Especially since GNOME and KDE changes a lot of stuff more often. Not to mention, with all the OSS activism going on and security issues, it is always better to have the least possible dependencies. Whatever is unnecessary for the default package could be optional dependencies always. Prevention is better than cure. Right? :)
Krop - https://flathub.org/apps/details/com.github.arminstraub.krop
My favorite okular feature is the way click-and-drag to pan wraps around between the top and the bottom of the screen. Excellent UX.
This can be made to work if you tell mime that zip is an alias for cbz: put
<?xml version="1.0"?>
<mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'>
<mime-type type="application/zip">
<alias type="application/x-cbz"/>
</mime-type>
</mime-info>
in ~/.local/share/mime/packages/some-name.xml then run "update-mime-database ~/.local/share/mime"I've had this for 2 years and 2 days and haven't noticed any issues.