Re: PDF viewer poll

Re: PDF viewer poll

[Damien Thiriet]

Hello,


I am using SumatraPDF at school (Windows). Lightweight, opens where it
was closed last time (very convenient when you've got presentations up
to 100 slides or more that takes several weeks to be discussed). Self
actualizes when the ConTeXt source is compiled.

At home (OpenBSD), mupdf and zathura. Rather for ratpoisons or Vim fans
(keyboard-driven).

Regards,


Damien Thiriet
___________________________________________________________________________________
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
___________________________________________________________________________________

PDF viewer poll

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


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
___________________________________________________________________________________

Re: PDF viewer poll

[denis.maier]

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 <ntg-context-bounces@ntg.nl> Im Auftrag von Henning Hraban Ramm
Gesendet: Sonntag, 13. Oktober 2019 12:43
An: mailing list for ConTeXt users <ntg-context@ntg.nl>
Betreff: [NTG-context] PDF viewer poll

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

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

Re: PDF viewer poll

[Rudolf Bahr]

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

Re: PDF viewer poll

[Henning Hraban Ramm]

> Am 2019-10-13 um 16:50 schrieb Rudolf Bahr <quasi@quasi.de>:
> 
> 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

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

Re: PDF viewer poll

[Pablo Rodriguez]

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

Re: PDF viewer poll

[Greedwolf DSS]

Henning Hraban Ramm <texml@fiee.net> writes:

pdf-tools in Emacs is well.
___________________________________________________________________________________
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
___________________________________________________________________________________

Re: PDF viewer poll

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

Re: PDF viewer poll

[kaddour kardio]

[-- Attachment #1.1: Type: text/plain, Size: 2190 bytes --]

- 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 <oinos@gmx.es> a écrit :

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

[-- Attachment #1.2: Type: text/html, Size: 3445 bytes --]

[-- Attachment #2: Type: text/plain, Size: 493 bytes --]

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

Re: PDF viewer poll

[Hans Åberg]

> On 13 Oct 2019, at 12:43, Henning Hraban Ramm <texml@fiee.net> 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. :-)


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

Re: PDF viewer poll

[Taco Hoekwater]

Hi,

> On 13 Oct 2019, at 12:43, Henning Hraban Ramm <texml@fiee.net> 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
___________________________________________________________________________________
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
___________________________________________________________________________________

Re: PDF viewer poll

[Hans Hagen]

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
___________________________________________________________________________________

Re: PDF viewer poll

[Henning Hraban Ramm]

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 <j.hagen@xs4all.nl>:
> 
> 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


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

Re: PDF viewer poll

[Marcin Borkowski]

On 2019-10-15, at 06:42, Henning Hraban Ramm <texml@fiee.net> wrote:

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

Re: PDF viewer poll

[Henning Hraban Ramm]

> Am 2019-10-15 um 08:17 schrieb Marcin Borkowski <mbork@mbork.pl>:
>>> 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


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

Re: PDF viewer poll

[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?).

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

Re: PDF viewer poll

[Henning Hraban Ramm]

> Am 2019-10-19 um 12:51 schrieb Hans Hagen <j.hagen@xs4all.nl>:
> 
> 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
___________________________________________________________________________________
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
___________________________________________________________________________________

Re: PDF viewer poll

[Marcin Borkowski]

On 2019-10-19, at 12:21, Henning Hraban Ramm <texml@fiee.net> wrote:

>> Am 2019-10-15 um 08:17 schrieb Marcin Borkowski <mbork@mbork.pl>:
>>>> 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
___________________________________________________________________________________
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
___________________________________________________________________________________

Re: PDF viewer poll

[Hans Hagen]

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

Re: PDF viewer poll

[Hans Hagen]

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

Re: PDF viewer poll

[Taco Hoekwater]

> On 15 Oct 2019, at 06:42, Henning Hraban Ramm <texml@fiee.net> 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 <j.hagen@xs4all.nl>:
>> 
>> 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


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

Re: PDF viewer poll

[Hans Hagen]

On 10/15/2019 10:12 AM, Taco Hoekwater wrote:
> 
> 
>> On 15 Oct 2019, at 06:42, Henning Hraban Ramm <texml@fiee.net> 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 <j.hagen@xs4all.nl>:
>>>
>>> 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
-----------------------------------------------------------------
___________________________________________________________________________________
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
___________________________________________________________________________________

Re: PDF viewer poll

[luigi scarso]

[-- Attachment #1.1: Type: text/plain, Size: 354 bytes --]

On Tue, Oct 15, 2019 at 10:21 AM Hans Hagen <j.hagen@xs4all.nl> wrote:

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

[-- Attachment #1.2: Type: text/html, Size: 781 bytes --]

[-- Attachment #2: Type: text/plain, Size: 493 bytes --]

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

Re: PDF viewer poll

[luigi scarso]

[-- Attachment #1.1: Type: text/plain, Size: 1778 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2433 bytes --]

[-- Attachment #2: Type: text/plain, Size: 493 bytes --]

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

Re: PDF viewer poll

[Marcin Borkowski]

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 <texml@fiee.net> 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
___________________________________________________________________________________

Re: PDF viewer poll

[Benct Philip Jonsson]

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 <texml@fiee.net> 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
> ___________________________________________________________________________________
> 

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

Re: PDF viewer poll

[Alan Braslau]

On Sun, 13 Oct 2019 12:43:14 +0200
Henning Hraban Ramm <texml@fiee.net> wrote:

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

Re: PDF viewer poll

[Hamid,Idris]

Hi Henning, all,

On Sun, 13 Oct 2019 04:43:14 -0600, Henning Hraban Ramm <texml@fiee.net>  
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.

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

Re: PDF viewer poll

[Henning Hraban Ramm]

Hi, nice to read you again!

(BTW what’s the state of Husayni fonts?)


> Am 2019-10-15 um 06:58 schrieb Hamid,Idris <Idris.Hamid@ColoState.EDU>:
> 
> 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

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

Re: PDF viewer poll

[Otared Kavian]

> On 13 Oct 2019, at 12:43, Henning Hraban Ramm <texml@fiee.net> 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
___________________________________________________________________________________
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
___________________________________________________________________________________

Re: PDF viewer poll

[luigi scarso]

[-- Attachment #1.1: Type: text/plain, Size: 373 bytes --]

On Sun, Oct 13, 2019 at 12:43 PM Henning Hraban Ramm <texml@fiee.net> wrote:

> 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

[-- Attachment #1.2: Type: text/html, Size: 771 bytes --]

[-- Attachment #2: Type: text/plain, Size: 493 bytes --]

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

Re: PDF viewer poll

[context]

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