[NTG-context] PDF viewer poll
j.hagen at xs4all.nl
Mon Oct 14 11:17:50 CEST 2019
On 10/13/2019 12:43 PM, Henning Hraban Ramm wrote:
> Hi, I’d like to update my list of (usable!) PDF viewers.
> Which one do you use? (Current version?)
> What are its pros and cons?
> Is it free (open source, freeware)?
> Does it work on Win/Lin/Mac?
> Does it have a localized interface? (I don’t care, but I work with people who don’t understand a lot of English.)
> Can it handle comments, attachments?
> Does it support SyncTeX? (Who uses that anyway?)
> Does it update changed PDFs on its own (or does it even block overwriting)?
> Which other features are essential for your choice?
> E.g. I’m working with:
> - Preview.app (Mac)
> Default on MacOS, fast & easy. No JS, bad forms support, updates "sometimes". Usable as a previewer, not as a PDF toolbox.
> - Adobe Reader DC (Mac)
> I use it only to check forms or as reference. Unusable GUI.
> - Acrobat Pro 9 (Mac)
> Was my workhorse, but works on MacOS Mojave only partly; slow & crash-prone; no updates. Can check PDF/X<4 and convert colors.
> - PDF Studio Pro (on Mac & Linux)
> Bought to replace AcroPro9; JS support broken; slow startup; no updates. Can check PDF/X, A, UA and convert colors.
> Ok with forms, but doesn’t support LiveCycle forms (deprecated, but used by German boards).
> - Qpdfview (Linux)
> Fast and easy; reliably updates.
> - PDF.js (Browser or Atom)
> Is said to do SyncTeX (never tried). Easy, but slow. Updates.
=== viewing ===
99% of the time i use the mupdf based sumatrappdf (which has not been
updated for a while, not that it seems to matter much)
I also occasionally use the gui that comes with mupdf but it is limited
(no bookview for instance; if that was there + printing I'd use it more
often) ... mupdf started simple but I think it also grew in a weird
direction (large codebase, some reflow I think, a strange epub
substandard support, etc .. all pretty useless to me and I'm not sure
how optional it it ... so no longer as lightweight as it could be ...)
When developing pdf specific code (like last months) I do use acrobat
reader and an older acrobat x (which keeps telling me that it wants to
be updated but the update fails) ... both have their different issues.
Acrobat X has some validation on board and one can introspect the file
(and fonts) to some extend but in the end it's often still trial and error.
It's no problem keeping sumatrapdf open when processing a file, it even
goes to the same spot (if possible). Acrobat is cumbersome (I can
understand why it was the case when mem was low as some caching happens.)
(When browsing and opening a pdf chrome uses the built-in, firefox the
reader and edge the build in. Last time I checked edge was the best in
I have okular installed but I think what i installed is too old by now.
When it comes to for instance cut and paste (testing) I think open
source viewers never catched on (and there has been plenty of time to do
it). I sometimes suspect build-in fixes (heuristics) for situations but
i might be wrong in that. Ok, it's volunteers work, so no complaints;
and I can use mupdf quite well.
=== checking ===
On the commandline, when I need to check a pdf I sometimes use qpf
(quite ok but I always need to stepwise build the commandline using help
as it's somewhat complex). The other command line tool I use is mutool
(mudraw) which is different but also ok.
=== verdict ===
In general I think that mupdf has the best viewer code, and qpdf the
best commandline stuff (no viewing code). Acrobat used to be ok upto
version 6 (I even remember the msdos version to be ok) but each version
the user interface changed fo rthe worse (very bad imo and an
indication that it's not meant for power usage as there one wants at
least an upward compatible interface) and it's slower compared to other
viewers (probably due to color management). With acrobat moving to the
cloud and with all these sharing and validation and security stuff built
it became kind of unuseable for every day use. It demonstrates that one
cannot easilly mix a commercial product with a general 'standadized'
format vor document distribution (I'm not even sure if there has been a
long term agenda involved). I'm not going to lock into some subscription
model for something that i hardly use (Do they really expect people to
subscribe when their employer is not paying for it? If one retires then
...). I have no problem paying for something but it has to be in
proportion (and on the average everything pdf has cost us more than in
=== synctex ===
I don't use it myself. I think that it being a library that has to be
linked in is a bad design decision: it could have been a call to an
external program that gets the filename + page and position and then
returns the source file and line. That way it would a future proof
system with no dependencies. There could a way better feedback then too.
(Context already ships a script that does that.) Not all viewers updated
to the latest synctex version anyway, which proves the point.
setting annotation properties, like toggling layers or button
renditions, and (2) some simple calculations (for forms). Constructing
interfacing to some mupdf library stuff than to dealing with the
annotations. So, for me useless.
It is one of the puzzling areas to me: no problem in browsers and
elsewhere but not in open source pdf viewers. It's not the most complex
stuff so it probably indicates that no one cares much about these features.
was in the manual and in the acrobat viewer but that 'handcrafted pdf'
was used for testing. By the time (adobe) applications started
supporting it, some functionality changed (easy when the manual is
vague). Bugs became features and so on.
It is still on my agenda to see if the context community can add a lua
interface to mupdf (with a proper lua annotation): kind of have a
reference viewer as simple as possible. But I need to get Taco on board
for that (i'm pretty sure that as with initial luatex we can wrap that
=== annotations ===
Some useful stuff was dropped: like native sound and movies (was very
simple: show a movie, play a sound, simple annotations). What seems to
be natural to html became complex and unuseable in pdf ... the media
subsystem is (obsolete) flash based, imo mostly driven by third party
commercial pressure / demand / whatever. Not future safe, if working at
all: from simple to complex to useless. In a similar fashion forms (for
some widgets bugs because features esp default rendering, inheritance,
etc and also some strange relation with viewer settings, that change per
version). It made me loose interest it those things that once were
(Some of the bad in pdf is a result from it being a container format for
a lot of things: documents, editing tools, printing, application stuff
turned annotation, etc.).
=== accessibility ===
Puzzles me. If someone wants to have something accessible, start from
the source and provide tools. In fact, one can add the source to a pdf,
but no publisher is willing to publish a source (xml). Or go html (which
is then also kind of publishing a source). I'm also not sure what the
real role is of publishers: are there actually still real publishers
around anyway? As far as I can tell publishers haven't spent a dollar /
euro on innovation anyway, so all they can be is patient: I feel no
pressure in that area. Go for the best solution or just stick to what
one has. Anyway, validation always has been (and is) big business (far
away from the tex community I guess) so that is a driving force too.
We'll see. (My pov: so far all that is needed could be accomodated
pretty easy and fast and often ahead of demand, which then proved to be
kind of non-existent, so we don't have to fearwhatever else is asked
for. (It only works for acrobat anyway.)
=== so much on pdf (viewers) ===
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
More information about the ntg-context