![](https://secure.gravatar.com/avatar/e5aa6984b53b8925e405ebbdbc051ad9.jpg?s=120&d=mm&r=g)
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. Curious: Hraban
![](https://secure.gravatar.com/avatar/6703e331415b033c63b618d132000a1f.jpg?s=120&d=mm&r=g)
SumtraPDF on Windows
Easy, fast, quite basic. (I take this as an advantage)
Interface is localized.
Forms: don't know
Free
Synctex: Don't need it at the moment, but the documentation says it should be supported
Updates automatically
Hope this helps,
Denis
-----Ursprüngliche Nachricht-----
Von: ntg-context
![](https://secure.gravatar.com/avatar/5347b1604e2495e607f617fe6297b881.jpg?s=120&d=mm&r=g)
On Sun, Oct 13, 2019 at 12:43:14PM +0200, 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.
Curious: Hraban
Hello Hraban, I'm working with only 2 pdf-viewers, "okular" and "xpdf". My main-viewer is "okular", but at the moment it doesn't work with my context-pdfs, I don't know why, but I don't care. Then it's good to have "xpdf" which is simpler than "okular" but works especially in this case. And before sending pdf-data to a printing-house I use "qpdf" not to view, but to transform my pdf files as rotate them to get them binded at a book side not offered by printers. All 3 programs are open source on Linux and because I'm updating regularly my OS, those programs are regularly updated too. JS? Form support? PDF/X/A/UA? Convert colors? SyncTex? Handle comments? I'm not using any of these. To some of them I can't say anything, because I dont't even know, what they are good for. So, I'm sorry not to be able to say more to those possible properties of my used programs: "okular": version: 1.6.3 Manual in German "xpdf": version: 3.04 Manual in English "qpdf": version: 8.4.0 Manual in English Best wishes, Rudolf
![](https://secure.gravatar.com/avatar/e5aa6984b53b8925e405ebbdbc051ad9.jpg?s=120&d=mm&r=g)
Am 2019-10-13 um 16:50 schrieb Rudolf Bahr
: Hello Hraban,
I'm working with only 2 pdf-viewers, "okular" and "xpdf". My main-viewer is "okular", but at the moment it doesn't work with my context-pdfs, I don't know why, but I don't care. Then it's good to have "xpdf" which is simpler than "okular" but works especially in this case. And before sending pdf-data to a printing-house I use "qpdf" not to view, but to transform my pdf files as rotate them to get them binded at a book side not offered by printers.
All 3 programs are open source on Linux and because I'm updating regularly my OS, those programs are regularly updated too. JS? Form support? PDF/X/A/UA? Convert colors? SyncTex? Handle comments? I'm not using any of these. To some of them I can't say anything, because I dont't even know, what they are good for. So, I'm sorry not to be able to say more to those possible properties of my used programs:
Thank you! xpdf I found a bit too basic for my taste. And it’s also based on poppler nowadays, like Qpdfview and several others. Of course there are a lot of features that one could compare, e.g. presentation control or printing options. Since I regularly need to send pdfs to the printers, I need to check if they will print correctly. That’s what PDF/X is for. Often it’s easier to convert colors in the PDF instead of finding and converting the elements separately. (I don’t convert RGB to CMYK, printshop workflows can handle this, but e.g. ensuring everything’s grayscale can save costs in digital printing. And sometimes I get logos in spot colors...) I never used SyncTeX myself, but I guess it would make my correction workflows easier. And I usually get corrections as comments in PDFs. Forms support I usually need only to fill in some official forms, but I got one customer with a ConTeXt-set form of >30 pages… And that’s one area where ConTeXt is a bit buggy (e.g. radiobuttons don’t work), and I’d like to debug that. I was only asking for "current version", because some folks still use acroread on Linux, and that was last updated in 2005 (I think), and some other readers aren’t updated any more, e.g. Nitro. Greetlings, Hraban --- https://www.fiee.net http://wiki.contextgarden.net https://www.dreiviertelhaus.de GPG Key ID 1C9B22FD
![](https://secure.gravatar.com/avatar/5955e8e90611e77ccbfc7721b6112027.jpg?s=120&d=mm&r=g)
On 10/13/19 5:26 PM, Henning Hraban Ramm wrote:
[...] xpdf I found a bit too basic for my taste. And it’s also based on poppler nowadays, like Qpdfview and several others. Hi Hraban,
just for the record, poppler is a fork of xpdf-3 (from https://poppler.freedesktop.org/). Pablo -- http://www.ousia.tk
![](https://secure.gravatar.com/avatar/5955e8e90611e77ccbfc7721b6112027.jpg?s=120&d=mm&r=g)
On 10/13/19 12:43 PM, Henning Hraban Ramm wrote:
Hi, I’d like to update my list of (usable!) PDF viewers.
1. Evince-3.28.5, MuPDF-1.16.1 and (sometimes) acroread-9.5.5 on Linux. 2. SumatraPDF, MuPDF and Acrobat Reader DC on Windows. From MuPDF, I use mupdf-gl (just in case it might be relevant). They are zero cost programs. Except Acrobat, all of them are FLOSS. SumatraPDF is Windows only. mupdf runs on Linux, Windows, Android and iOS. mupdf has an English-only help. All the other programs have localized interfaces. Evince can handle comments and attachments. mupdf can handle comments, but not attachments. Sumatra cannot handle comments, but it does handle embedded files. Evince can handle forms without JS (support is on the way). mupdf can handle forms with JS (but I would say that JS support in MuPDF is incomplete). SumatraPDF cannot handle forms. I don’t use SyncTeX myself, so I don’t know whether it is supported or not. Evince and SumatraPDF reload modified documents automatically. mupdf-gl allows document reloading with the 'r' key. My basic features are bookmarks, links and attachments. Evince and SumatraPDF can handle all of them. mupdf-gl cannot handle attachments and partial implementation for bookmarks. Just in case it helps, Pablo -- http://www.ousia.tk
![](https://secure.gravatar.com/avatar/b5d2903e067e6b61ca41c97939b81961.jpg?s=120&d=mm&r=g)
- Okular v1.8.1 on my linux machines.
- SumatraPDF on windows at work (that never use for my ConTeXT related work)
Le dim. 13 oct. 2019 à 17:49, Pablo Rodriguez
On 10/13/19 12:43 PM, Henning Hraban Ramm wrote:
Hi, I’d like to update my list of (usable!) PDF viewers.
1. Evince-3.28.5, MuPDF-1.16.1 and (sometimes) acroread-9.5.5 on Linux. 2. SumatraPDF, MuPDF and Acrobat Reader DC on Windows.
From MuPDF, I use mupdf-gl (just in case it might be relevant).
They are zero cost programs. Except Acrobat, all of them are FLOSS.
SumatraPDF is Windows only. mupdf runs on Linux, Windows, Android and iOS.
mupdf has an English-only help. All the other programs have localized interfaces.
Evince can handle comments and attachments. mupdf can handle comments, but not attachments. Sumatra cannot handle comments, but it does handle embedded files.
Evince can handle forms without JS (support is on the way). mupdf can handle forms with JS (but I would say that JS support in MuPDF is incomplete). SumatraPDF cannot handle forms.
I don’t use SyncTeX myself, so I don’t know whether it is supported or not.
Evince and SumatraPDF reload modified documents automatically. mupdf-gl allows document reloading with the 'r' key.
My basic features are bookmarks, links and attachments. Evince and SumatraPDF can handle all of them. mupdf-gl cannot handle attachments and partial implementation for bookmarks.
Just in case it helps,
Pablo -- http://www.ousia.tk
___________________________________________________________________________________ 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
___________________________________________________________________________________
-- Dr YAHYAOUI Mohamed Kaddour, cardiologue .
![](https://secure.gravatar.com/avatar/d558f7d2c62b984d42b1e276bbdfc2c7.jpg?s=120&d=mm&r=g)
On 13 Oct 2019, at 12:43, Henning Hraban Ramm
wrote: Hi, I’d like to update my list of (usable!) PDF viewers. Which one do you use? (Current version?)
There is TeXShop that comes with the Mac TeX Live distribution. It can be set up to compile ConTeXt.
What are its pros and cons?
You might let us know, if you so will. :-)
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Hi,
On 13 Oct 2019, at 12:43, Henning Hraban Ramm
wrote: Hi, I’d like to update my list of (usable!) PDF viewers. Which one do you use? (Current version?)
Preview.App (Mac) — since it is fast and the MacOS default. But it does not handle anything well except the actual page display. Auto-refreshes, but only if the pdf update is finished when you switch back to the preview window. If the pdf is still being updated then, it produces an error and refuses to update any more after that. That is really annoying, which is why I am trying to switch to: mupdf-gl — trying to get used to that, but it is not an actual application according to MacOS, so it only works from the command-line in Terminal. Not sure about features, but it is fast. I should create a wrapper app script so I can use it more often. Refreshes with Cmd-R (and SIGHUP, since 1.15), but not automatically. mostly keyboard-driven, which works fine for me but may be a negative for other users. Acrobat Reader DC — but only if I really have to because of forms/js/attachments/etc. I do not object to commercial software, but I think the newer Adobe Apps are horrible in use. The last one with a ‘sane’ interface was version 9.0 or so. I only really care about (speed of) page display; I normally don’t need the interactive stuff. I never use synctex since most of my docs are quite short. No idea what pdf view supports it (and does it not need editor support as well? no idea what editors support it, either). Best wishes, Taco
![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/e5aa6984b53b8925e405ebbdbc051ad9.jpg?s=120&d=mm&r=g)
Thank you all for you valuable insights so far! I’ll compile them to a wiki page and also complete the list in my upcoming book.
Am 2019-10-14 um 11:17 schrieb Hans Hagen
: 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.
Do you know any other tools for PDF debugging? Those few I know of cost four to five figures or were plugins to very old versions of Acrobat.
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.
Need to look into those.
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).
I agree. Adobe needlessly changed the interface with every release, and it didn’t get better. There were different translation errors (at least in the German interface) in every version, and they never got fixed with the updates. Updates were announced by the Updater, but never installed. Don’t know about the speed – some functions like certificate lookup were always dead slow, and the display speed was mostly ok. (I should benchmark different viewers with my OpenStreetMap vector maps…) I found Qoppa’s PDF Studio Pro a viable alternative to Acrobat Pro with a usable interface (default has ribbons, but you can switch it). Their customer support is friendly, I hope they will also fix the problems I reported.
=== javascript === Only acrobat offers that.
Not completely true. But there aren’t a lot of apps that support JS in PDF - for a reason: if you allow scripting, you create a lot of vulnerabilities that you can easily avoid leaving out this feature that "nobody" needs. It would have made sense to define a small and safe JS (or whatever scripting language) _subset_ from the start, but the early versions of Acrobat were completely "hackable", and they only much later thought about security (like in lots of other programs). PDF viruses existed.
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).
D’accord.
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.
I wouldn’t say "no problem", because JS causes security problems everywhere.
=== 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.
If I remember correctly, Adobe first based the media subsystem on Apple’s Quicktime until Apple discontinued that on Windows and Adobe bought Macromedia, including Flash. 3D media was a short hype, nobody used it. Anyway, doesn’t matter. Nowadays PDF doesn’t have any working media subsystem.
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.
I can understand that, but at least ConTeXt’s radiobuttons *have* bugs; the few viewers that support forms stumble over some parsing/nesting error. Adobe catches it apparently.
(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.).
D’accord. Herzliche Grüße, Hraban
![](https://secure.gravatar.com/avatar/563a93bb88cdce75d836e1cb3828fdce.jpg?s=120&d=mm&r=g)
On 2019-10-15, at 06:42, Henning Hraban Ramm
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).
D’accord.
Of course you are aware that limiting a powerful language is not an easy task?
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.
I wouldn’t say "no problem", because JS causes security problems everywhere.
It's not JS that causes problems. Any other (powerful enough) language not specifically designed with browser environment in mind could be problematic here. I guess that having Perl, Python or Ruby instead of JS would create a similar set of problems. (Lua might be an exception due to its design and a possibility to whitelist functions for eval, AFAIR.) Just 2 cents from a JS programmer who actually thinks that JS is not the worst Lisp dialect out there. Best, -- Marcin Borkowski http://mbork.pl
![](https://secure.gravatar.com/avatar/e5aa6984b53b8925e405ebbdbc051ad9.jpg?s=120&d=mm&r=g)
Am 2019-10-15 um 08:17 schrieb Marcin Borkowski
: 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).
D’accord.
Of course you are aware that limiting a powerful language is not an easy task?
I am. But JS in PDF is completely different from PDF in browsers anyway (no DOM!), so they don’t need a complete interpreter and could have limited PDF scripting to a few commands, in JS syntax or anything else.
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.
I wouldn’t say "no problem", because JS causes security problems everywhere.
It's not JS that causes problems. Any other (powerful enough) language not specifically designed with browser environment in mind could be problematic here. I guess that having Perl, Python or Ruby instead of JS would create a similar set of problems. (Lua might be an exception due to its design and a possibility to whitelist functions for eval, AFAIR.)
Of course any programming language is a security risk. More so if it runs in an ubiquitous program like a browser. And since they created JavaScript for that, JS causes problems. When I read "Java runs on millions of devices" I don’t feel that’s good advertising, but it remembers me that each of those devices is at risk.
Just 2 cents from a JS programmer who actually thinks that JS is not the worst Lisp dialect out there.
I didn’t say JS is bad. For me it’s a necessary evil. I don’t think my beloved Python would be a better choice for client scripts. Maybe Lua is, but every scriptable program is a risk. LuaTeX and write18 _are_ dangerous. It would be very easy to spread malicious TeX code, since everyone uses CTAN (LaTeX) packages without checking them first. But it wouldn’t come far, I guess, for it needs a while for a package to become known and in wide use, and that still means only in a subset of the (La)TeX community, where there are enough expert hackers who would find this malicious code. And you can count the people on one hand who would be able to publish a malicious ConTeXt module… Malicious code snippets in our wiki or ML also wouldn’t come far. There was PDF malware (using JS or media stuff). There also was PostScript malware in its time. The latter didn’t make a lot of sense, except it could destroy RIP hardware. The RIP technician at the newspaper where I worked told me stories, e.g. there was an evil EPS (some faulty customer logo, no deliberate malware) that caused the deletion of important parts of the RIP software. At my time there was a PS ghost: somehow a page got installed on one of the printers and got printed at odd times. Reboot didn’t help, we never found the cause. Best, Hraban
![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
On 10/19/2019 12:21 PM, Henning Hraban Ramm wrote:
When I read "Java runs on millions of devices" I don’t feel that’s good advertising, but it remembers me that each of those devices is at risk.
The java updates keept telling that it runs on 3 billion devices but that message doesn't change over years. I always wonder about numbers. One can find similar huge numbers for tex usage but what defines usage (forced? ontime? for fun? lifelong? advanced or like any word processor usage?).
Just 2 cents from a JS programmer who actually thinks that JS is not the worst Lisp dialect out there.
I didn’t say JS is bad. For me it’s a necessary evil. I don’t think my beloved Python would be a better choice for client scripts. Maybe Lua is, but every scriptable program is a risk.
The fact that it's simple kind of helps. One can disable by overloading.
LuaTeX and write18 _are_ dangerous.
Sure, so can be crossing a street. Anyway, for quite a while there actually is a sandbox model in context which can limit its scope pretty much but it (being done a while ago) hasn't been tested that much (afer all I dont' need it).
It would be very easy to spread malicious TeX code, since everyone uses CTAN (LaTeX) packages without checking them first. But it wouldn’t come far, I guess, for it needs a while for a package to become known and in wide use, and that still means only in a subset of the (La)TeX community, where there are enough expert hackers who would find this malicious code. And you can count the people on one hand who would be able to publish a malicious ConTeXt module… Malicious code snippets in our wiki or ML also wouldn’t come far.
Also, I tend to stay optimistic. If there were way more strict rules for software abuse (with hard penalties) it would be less of a problem, but for now we just have to trust. So, far we could trust texies.
There was PDF malware (using JS or media stuff). There also was PostScript malware in its time. The latter didn’t make a lot of sense, except it could destroy RIP hardware. The RIP technician at the newspaper where I worked told me stories, e.g. there was an evil EPS (some faulty customer logo, no deliberate malware) that caused the deletion of important parts of the RIP software. At my time there was a PS ghost: somehow a page got installed on one of the printers and got printed at odd times. Reboot didn’t help, we never found the cause. Writing could be restricted I guess, so wiping rip source is also bit of a bug in the rip i guess. Anyway, I do remember sending postscript to our printer just to find out that you ended up with an empty paperbin and a few lines per page with garbage ascii. In that respect pdf is a bit better: something or nothing gets printed.
This ghost: makes for nice debugging. Kind of a challenge. (btw, this makes for a nice topic next meeting: security and documents and such) 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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/e5aa6984b53b8925e405ebbdbc051ad9.jpg?s=120&d=mm&r=g)
Am 2019-10-19 um 12:51 schrieb Hans Hagen
: On 10/19/2019 12:21 PM, Henning Hraban Ramm wrote:
When I read "Java runs on millions of devices" I don’t feel that’s good advertising, but it remembers me that each of those devices is at risk.
The java updates keept telling that it runs on 3 billion devices but that message doesn't change over years. I always wonder about numbers. One can find similar huge numbers for tex usage but what defines usage (forced? ontime? for fun? lifelong? advanced or like any word processor usage?).
Jep. And it doesn’t help if my washing machine runs Java if I can’t change the program. (Or play Tetris on it while waiting, or whatever.)
It would be very easy to spread malicious TeX code, since everyone uses CTAN (LaTeX) packages without checking them first. But it wouldn’t come far, I guess, for it needs a while for a package to become known and in wide use, and that still means only in a subset of the (La)TeX community, where there are enough expert hackers who would find this malicious code. And you can count the people on one hand who would be able to publish a malicious ConTeXt module… Malicious code snippets in our wiki or ML also wouldn’t come far.
Also, I tend to stay optimistic. If there were way more strict rules for software abuse (with hard penalties) it would be less of a problem, but for now we just have to trust. So, far we could trust texies.
Exactly. I guess it makes sense to be aware that there is a risk, but on the other hand the risk is quite neglectable, depending on your own programming skills… (I managed to mess up a git repository last week, trying to rename a file in all of the branches. Big pro of SCM repositories: you can restore them.)
There was PDF malware (using JS or media stuff). There also was PostScript malware in its time. The latter didn’t make a lot of sense, except it could destroy RIP hardware. The RIP technician at the newspaper where I worked told me stories, e.g. there was an evil EPS (some faulty customer logo, no deliberate malware) that caused the deletion of important parts of the RIP software. At my time there was a PS ghost: somehow a page got installed on one of the printers and got printed at odd times. Reboot didn’t help, we never found the cause. Writing could be restricted I guess, so wiping rip source is also bit of a bug in the rip i guess. Anyway, I do remember sending postscript to our printer just to find out that you ended up with an empty paperbin and a few lines per page with garbage ascii. In that respect pdf is a bit better: something or nothing gets printed.
This ghost: makes for nice debugging. Kind of a challenge.
We weren’t up to it, and it was just a minor annoyance. Maybe the problem was not really in the printer but in the print spooler of one workstation, so that the job was printed every time it was switched on or some user logged in.
(btw, this makes for a nice topic next meeting: security and documents and such)
No, that’s boring ;) Best, Hraban
![](https://secure.gravatar.com/avatar/563a93bb88cdce75d836e1cb3828fdce.jpg?s=120&d=mm&r=g)
On 2019-10-19, at 12:21, Henning Hraban Ramm
Am 2019-10-15 um 08:17 schrieb Marcin Borkowski
: 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).
D’accord.
Of course you are aware that limiting a powerful language is not an easy task?
I am. But JS in PDF is completely different from PDF in browsers anyway (no DOM!), so they don’t need a complete interpreter and could have limited PDF scripting to a few commands, in JS syntax or anything else.
Fair enough, although I don't have an association JS <-> browser ingrained so much - for me, JS is a general purpose language which happens to be embedded in browsers, but also many other places. Most of my JS code runs either on a server (backend code) or in a development environment (various, let's call it, DevOps-ish scripts). Only now and then I write JS for browsers, and then it is often crippled JS, full of things like "var" (because old browsers etc.)
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.
I wouldn’t say "no problem", because JS causes security problems everywhere.
It's not JS that causes problems. Any other (powerful enough) language not specifically designed with browser environment in mind could be problematic here. I guess that having Perl, Python or Ruby instead of JS would create a similar set of problems. (Lua might be an exception due to its design and a possibility to whitelist functions for eval, AFAIR.)
Of course any programming language is a security risk. More so if it runs in an ubiquitous program like a browser. And since they created JavaScript for that, JS causes problems.
When I read "Java runs on millions of devices" I don’t feel that’s good advertising, but it remembers me that each of those devices is at risk.
I like this approach:-). There is also that old joke than "every time you install Java it gets moved from another device to yours", since the installer has been saying that "3 billion devices run Java" for almost two decades now.
Just 2 cents from a JS programmer who actually thinks that JS is not the worst Lisp dialect out there.
I didn’t say JS is bad. For me it’s a necessary evil. I don’t think my beloved Python would be a better choice for client scripts.
Python is a worse Lisp dialect than JS, but still nice. (Disclaimer: i have only written less than 1000 lines of Python in my life.)
Maybe Lua is, but every scriptable program is a risk. LuaTeX and write18 _are_ dangerous. It would be very easy to spread malicious TeX code, since everyone uses CTAN (LaTeX) packages without checking them first. But it wouldn’t come far, I guess, for it needs a while for a package to become known and in wide use, and that still means only in a subset of the (La)TeX community, where there are enough expert hackers who would find this malicious code.
Assuming that they would search for it. I'm less of an optimist here.
And you can count the people on one hand who would be able to publish a malicious ConTeXt module… Malicious code snippets in our wiki or ML also wouldn’t come far.
That's interesting. It would be enough to have a "plain TeX virus", probably. I guess the main reason malicious ConTeXt code does not exist (assuming this is the case!) is that it is not economically viable - the ConTeXt community is too small.
There was PDF malware (using JS or media stuff). There also was PostScript malware in its time. The latter didn’t make a lot of sense, except it could destroy RIP hardware. The RIP technician at the newspaper where I worked told me stories, e.g. there was an evil EPS (some faulty customer logo, no deliberate malware) that caused the deletion of important parts of the RIP software. At my time there was a PS ghost: somehow a page got installed on one of the printers and got printed at odd times. Reboot didn’t help, we never found the cause.
That's absolutely fascinating! Best, -- Marcin Borkowski http://mbork.pl
![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
On 10/20/2019 10:15 PM, Marcin Borkowski wrote:
Maybe Lua is, but every scriptable program is a risk. LuaTeX and write18 _are_ dangerous. It would be very easy to spread malicious TeX code, since everyone uses CTAN (LaTeX) packages without checking them first. But it wouldn’t come far, I guess, for it needs a while for a package to become known and in wide use, and that still means only in a subset of the (La)TeX community, where there are enough expert hackers who would find this malicious code.
Assuming that they would search for it. I'm less of an optimist here. no problem getting a hit on a search
https://www.usenix.org/system/files/login/articles/73506-checkoway.pdf ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
On 10/15/2019 6:42 AM, Henning Hraban Ramm wrote:
Do you know any other tools for PDF debugging? Those few I know of cost four to five figures or were plugins to very old versions of Acrobat.
normally i trust my eyes and mind and 'standard' ... if it really get hairy there are a few folks one can ask for a second opinion
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).
I agree. Adobe needlessly changed the interface with every release, and it didn’t get better. There were different translation errors (at least in the German interface) in every version, and they never got fixed with the updates. Updates were announced by the Updater, but never installed. Don’t know about the speed – some functions like certificate lookup were always dead slow, and the display speed was mostly ok. (I should benchmark different viewers with my OpenStreetMap vector maps…)
speed is ok, but when using acrobat one has to close/open which takes time (and then go to the right spot again)
I found Qoppa’s PDF Studio Pro a viable alternative to Acrobat Pro with a usable interface (default has ribbons, but you can switch it). Their customer support is friendly, I hope they will also fix the problems I reported.
i must admit that i never used these alternatives (and i'm not going to spend money on programs just for testing)
=== javascript === Only acrobat offers that.
Not completely true. But there aren’t a lot of apps that support JS in PDF - for a reason: if you allow scripting, you create a lot of vulnerabilities that you can easily avoid leaving out this feature that "nobody" needs. It would have made sense to define a small and safe JS (or whatever scripting language) _subset_ from the start, but the early versions of Acrobat were completely "hackable", and they only much later thought about security (like in lots of other programs). PDF viruses existed.
i always wondered why they added all those 'editing features' ... the hold plugging was also kind of random
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).
D’accord.
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.
I wouldn’t say "no problem", because JS causes security problems everywhere.
Depends: enabling a layer? checking a value in a field? turning a button appearance on / off? Only lousy programing can make that buggy. A reasonable subsset can be made pretty robust. Launching a video is also quite harmless.
=== 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.
If I remember correctly, Adobe first based the media subsystem on Apple’s Quicktime until Apple discontinued that on Windows and Adobe bought Macromedia, including Flash. 3D media was a short hype, nobody used it. Anyway, doesn’t matter. Nowadays PDF doesn’t have any working media subsystem.
indeed. but just supporting mp3, flac and mp4 and maybe a few video formats would be enough ... i guess that there are plenty of libs out they that they vould use (but instead they went for flash and flash driven controls and pretty complex 3d stuff)
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.
I can understand that, but at least ConTeXt’s radiobuttons *have* bugs; the few viewers that support forms stumble over some parsing/nesting error. Adobe catches it apparently.
they don't catch all (differs per version which is why the code changed over time) ... much has to do with appearances (mostly dingbat driven in acrobat itself, but we want different things, possible per standard, but these all have timing and initialization issues and some even have pseudo documented issues with what happens when a page opens ... i presume it works with their own tools but then these can impose limitations that texies never would like
(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.).
D’accord. 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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
On 15 Oct 2019, at 06:42, Henning Hraban Ramm
wrote: Thank you all for you valuable insights so far! I’ll compile them to a wiki page and also complete the list in my upcoming book.
Am 2019-10-14 um 11:17 schrieb Hans Hagen
: 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.
Do you know any other tools for PDF debugging? Those few I know of cost four to five figures or were plugins to very old versions of Acrobat
Most of my PDF debugging is done using 'mutool clean’ (especially with the -d switch) and textmate / diff. Best wishes, Taco
![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
On 10/15/2019 10:12 AM, Taco Hoekwater wrote:
On 15 Oct 2019, at 06:42, Henning Hraban Ramm
wrote: Thank you all for you valuable insights so far! I’ll compile them to a wiki page and also complete the list in my upcoming book.
Am 2019-10-14 um 11:17 schrieb Hans Hagen
: 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.
Do you know any other tools for PDF debugging? Those few I know of cost four to five figures or were plugins to very old versions of Acrobat
Most of my PDF debugging is done using 'mutool clean’ (especially with the -d switch) and textmate / diff.
qpdf also has something like that (with comments of where the objects come from) and using both tools in parallel can normally reveal issues there are catches: for instance some tools don't really use the xref table but just run through the objects so finding issues in the xref (and compressed object tables) is a bitch but luckily it seldom needed 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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/386a116d129cdc597f2bb6210bbaff7a.jpg?s=120&d=mm&r=g)
On Tue, Oct 15, 2019 at 10:21 AM Hans Hagen
Most of my PDF debugging is done using 'mutool clean’ (especially with the -d switch) and textmate / diff. qpdf also has something like that (with comments of where the objects come from)
it's the qdf export : pdf -> qdf -> (edit qdf) -> pdf -- luigi
![](https://secure.gravatar.com/avatar/386a116d129cdc597f2bb6210bbaff7a.jpg?s=120&d=mm&r=g)
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 ...)
mupdf-1.16.1-source/build/release$ du -sh platform resources source thirdparty 524K platform 42M resources 7.2M source 6.6M thirdparty where resources is a directory with 155 fonts compressed and embedded into the exe. Following (the quite old) pdf this should be configurable https://ghostscript.com/~robin/mupdf_explored.pdf (ch. 18) I guess that mupdf's targets are windows/mac/Linux/Android but as a base tool (eg ebook reader make senses on Android). License is AGPL https://mupdf.com/license.html like GPL plus """ Network Use – However, AGPL also has some conditions even if you are not distributing the software. For example, if you are using the software on your own company's equipment, but you are making the functionality of the software available to users interacting with it remotely through a computer network, and you make any change to the software, you must make the source code for your changed version available to users of the software. Take care to ensure that during network deployment that there is no code change that could invoke the source code availability obligation. This special requirement of AGPL is in Section 13; see the GNU web site for more details. Bottom line, if you distribute our software, or make the functionality of the software available to users interacting with it remotely through a computer network, you must share your source code. """ and also the "Corresponding Source " subsection. -- luigi
![](https://secure.gravatar.com/avatar/563a93bb88cdce75d836e1cb3828fdce.jpg?s=120&d=mm&r=g)
Hi,
I don't use ConTeXt anymore, but I still get the emails from the list,
and I quickly skimmed throught this thread to see if someone writes
about my pdf-viewer of choice - pdf-tools
(https://github.com/politza/pdf-tools).
On 2019-10-13, at 12:43, Henning Hraban Ramm
Hi, I’d like to update my list of (usable!) PDF viewers. Which one do you use? (Current version?)
pdf-tools (version 20190701.202)
What are its pros and cons?
cons: - no "continuous display"/"double page" modes pros: - searchable (also with regexen), also grep-like (i.e., display all lines containing some regex and jump to them easily) - annotations/comments are viewable (and jumpable to) w/o using the mouse - fast - runs within Emacs (not sure if this is a "pro" for everyone...)
Is it free (open source, freeware)?
yes (GPL3)
Does it work on Win/Lin/Mac?
GNU/Linux, maybe Mac
Does it have a localized interface? (I don’t care, but I work with people who don’t understand a lot of English.)
No.
Can it handle comments, attachments?
Yes.
Can it handle forms with or without JavaScript?
AFAIK, no.
Does it support SyncTeX? (Who uses that anyway?)
Yes, and I do all the time!
Does it update changed PDFs on its own (or does it even block overwriting)?
I guess it can be configured to do so (like Emacs in general)
Which other features are essential for your choice?
As I said - I don't have to leave Emacs. Also, incremental or grep-like searching with literal text or regexen are killer features. Best, -- Marcin Borkowski http://mbork.pl
![](https://secure.gravatar.com/avatar/47ca3ec1a95687653d19039588a40c50.jpg?s=120&d=mm&r=g)
On 2019-10-14 18:55, Marcin Borkowski wrote:
Hi,
I don't use ConTeXt anymore, but I still get the emails from the list, and I quickly skimmed throught this thread to see if someone writes about my pdf-viewer of choice - pdf-tools (https://github.com/politza/pdf-tools).
I too don't use context anymore[^1] but I thought I should mention Zathura which is a good alternative if you like vi(m) and/or dislike/have trouble using a GUI.[^2]. The WP page (and `man zathura`) describes its capabilities well without me needing to type them. :-) They include synctex but I don't use it. https://en.wikipedia.org/wiki/Zathura_(document_viewer) [^1]: I never really took off with context because I already know how to do 9 out of 10 tasks in LaTeX, and when I don't the info is much easier to find online. Sorry! [^2]: I have a motor disability which makes pointing with a mouse difficult and point-dragging almost impossible. That's the main reason I got into text-only/plaintext/non-gui workflows, but I keep on because I find them better. Unfortunately when computer accessibility is discussed it is almost synonymous with vision disability accessibility, but there are other reasons for having trouble with GUIs.
On 2019-10-13, at 12:43, Henning Hraban Ramm
wrote: Hi, I’d like to update my list of (usable!) PDF viewers. Which one do you use? (Current version?)
pdf-tools (version 20190701.202)
What are its pros and cons?
cons: - no "continuous display"/"double page" modes
pros: - searchable (also with regexen), also grep-like (i.e., display all lines containing some regex and jump to them easily) - annotations/comments are viewable (and jumpable to) w/o using the mouse - fast - runs within Emacs (not sure if this is a "pro" for everyone...)
Is it free (open source, freeware)?
yes (GPL3)
Does it work on Win/Lin/Mac?
GNU/Linux, maybe Mac
Does it have a localized interface? (I don’t care, but I work with people who don’t understand a lot of English.)
No.
Can it handle comments, attachments?
Yes.
Can it handle forms with or without JavaScript?
AFAIK, no.
Does it support SyncTeX? (Who uses that anyway?)
Yes, and I do all the time!
Does it update changed PDFs on its own (or does it even block overwriting)?
I guess it can be configured to do so (like Emacs in general)
Which other features are essential for your choice?
As I said - I don't have to leave Emacs. Also, incremental or grep-like searching with literal text or regexen are killer features.
Best,
-- Marcin Borkowski http://mbork.pl ___________________________________________________________________________________ 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 ___________________________________________________________________________________
![](https://secure.gravatar.com/avatar/6e50a7aa57f5569d881f204f124d96ef.jpg?s=120&d=mm&r=g)
On Sun, 13 Oct 2019 12:43:14 +0200
Henning Hraban Ramm
Hi, I’d like to update my list of (usable!) PDF viewers. Which one do you use? (Current version?)
On Mac OS, there is skim, which has better features than preview but uses the same Apple rendering engine (with all of its bugs). zathura (many systems) can use either the mupdf or the poppler engine. Your choice. mupdf-gl on MacOS doesn't need X11, but it has some annoying bugs that might get fixed ... someday. But, as Hans says, it should not be too hard to build a mupdf-engine based lightweight viewer with lua integrated. Or why not add this to lua-bloat-tex as an output option? That way, one can interpret (xml) source files with on the fly rendering. Alan
![](https://secure.gravatar.com/avatar/11bdb092d7681af7742fdd43617e975c.jpg?s=120&d=mm&r=g)
Hi Henning, all,
On Sun, 13 Oct 2019 04:43:14 -0600, Henning Hraban Ramm
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.
On Windows: For a ConTeXt workflow, sumatrapdf, for all the reasons mentioned by Hans and others. Works well with SyncTeX and Notepad++. As a commercial replacement to Adobe Acroboat, nothing beats NitroPDF. Clean interface. Avoids most if not all of the problems mentioned by Hans. University machine has Acrobat, so for pdf manipulation beyond the capabilities of sumatrapdf: mostly Acrobat at school and NitroPDF at home. Best wishes Idris -- Idris Samawi Hamid, Professor Department of Philosophy Colorado State University Fort Collins, CO 80512
![](https://secure.gravatar.com/avatar/e5aa6984b53b8925e405ebbdbc051ad9.jpg?s=120&d=mm&r=g)
Hi, nice to read you again! (BTW what’s the state of Husayni fonts?)
Am 2019-10-15 um 06:58 schrieb Hamid,Idris
: As a commercial replacement to Adobe Acroboat, nothing beats NitroPDF. Clean interface. Avoids most if not all of the problems mentioned by Hans.
I can’t check it out since i don’t use Windows, and their website is a lot of marketing fluff. So I hope you can tell me: Can/has Nitro… - check PDF/X, /A, /UA? (AFAIK only /A)* - convert colors (e.g. RGB->CMYK or any->grayscale)?* - update changed files (automatically or on key press)? - support SyncTeX? (probably not) - handle forms (print, save)? (probably yes) - support JavaScript? (probably not) - a localized interface? (probably yes) *) or general preflighting like Acrobat has Greetlings, Hraban --- https://www.fiee.net http://wiki.contextgarden.net https://www.dreiviertelhaus.de GPG Key ID 1C9B22FD
![](https://secure.gravatar.com/avatar/5faea8b4fa0adb143383811dc94f0d22.jpg?s=120&d=mm&r=g)
On 13 Oct 2019, at 12:43, Henning Hraban Ramm
wrote: Hi, I’d like to update my list of (usable!) PDF viewers. Which one do you use? (Current version?)
Hi Hraban, I am on MacOS and use the PDF viewer included in TeXShop (which is based on Preview.app of MacOS). For my presentations I use Adobe Acrobat Reader DC, but for readings on the screen the Preview.app of MacOS is just fine (one can also annotate a PDF file, but strangely when such files are used in ConTeXt the annotations disappear: so one has to transform them into a JPG then again into a PDF). I use extensively synctex within TeXShop, and although there has been a split in the way synctex is implemented in ConTeXt and other TeX flavors, it works fine. When writing lecture notes and math exercises, having synctex is fundamental for me. Best regards: OK
![](https://secure.gravatar.com/avatar/386a116d129cdc597f2bb6210bbaff7a.jpg?s=120&d=mm&r=g)
On Sun, Oct 13, 2019 at 12:43 PM Henning Hraban Ramm
Hi, I’d like to update my list of (usable!) PDF viewers.
A recent android tablet 10" with HD display is quite ok with Adobe Reader and several others apps ( eg foxit pdf reader) EBookDroid is another app pdf +djvu reader , also quite ok to read a pdf on screen. -- luigi
![](https://secure.gravatar.com/avatar/9291059911c26e0375f80003de0ea2fd.jpg?s=120&d=mm&r=g)
Hello, On 2019-10-13 12:43, Henning Hraban Ramm wrote:
Hi, I’d like to update my list of (usable!) PDF viewers. Which one do you use? (Current version?)
PDF XChange Viewer (https://www.tracker-software.com/product/pdf-xchange-viewer)
What are its pros and cons?
+ Free; not annoying as AR is; many functions included, restore last view, tabbed env, page thumbs navigator/bookmarks navigator, attachment list, comment list; OCR included; handy designed; (many command line options, e.g.) /open and /close options to be used by 3rd party programs; /printto for batch printing; printing also: tile large pages / print many pages on one sheet of paper; some "extras" require pro (non-free) version.
Is it free (open source, freeware)?
Free, not open source.
Does it work on Win/Lin/Mac?
Windows
Does it have a localized interface? (I don’t care, but I work with people who don’t understand a lot of English.)
Yes.
Can it handle comments, attachments?
Yes.
Can it handle forms with or without JavaScript?
Not using - don't know
Does it support SyncTeX? (Who uses that anyway?)
No.
Does it update changed PDFs on its own (or does it even block overwriting)?
No. With working with ConTeXt, I'm using a batch file which normally opens a copy of a PDF being compiled, and once it's (successfully) compiled, the batch reopens the PDF in the viewer.
Which other features are essential for your choice?
Handy work - after some time of using the prog, you see how much "handy" the program is, but hard to say which feature is essetial or most important; "total handyness" is the goal. I would probably change this PDF viewer just if synctex worked WELL with the source (and in my case - I'm using Lua in ConTeXt widely to generate the PDF, so in most cases synctech navigates me badly to the source). Best regards, Lukas
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.
Curious: Hraban ___________________________________________________________________________________ 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 ___________________________________________________________________________________
participants (16)
-
Alan Braslau
-
Benct Philip Jonsson
-
context@vivaldi.net
-
denis.maier@mailbox.org
-
Greedwolf DSS
-
Hamid,Idris
-
Hans Hagen
-
Hans Åberg
-
Henning Hraban Ramm
-
kaddour kardio
-
luigi scarso
-
Marcin Borkowski
-
Otared Kavian
-
Pablo Rodriguez
-
Rudolf Bahr
-
Taco Hoekwater