Re: PDF viewer poll

[Hans Hagen <j.hagen@xs4all.nl>]

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?
> Can it handle forms with or without JavaScript?
> 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 
that.)

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 
brought 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.

=== javascript ===

Only acrobat offers that. Basically javascript can be limited to (1) 
setting annotation properties, like toggling layers or button 
renditions, and (2) some simple calculations (for forms). Constructing 
pdf runtime using javascript is pretty braindead (use html instead then).

Afaik mupdf has some javascript but none of the above, it's more about 
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.

One handicap is that often the javascript (and even some pdf trickery) 
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 
up fast).

=== 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 
promising.

(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


-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________