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