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

On 2019-10-15, at 06:42, Henning Hraban Ramm 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

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

On 2019-10-19, at 12:21, Henning Hraban Ramm wrote:

...

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

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

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

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

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 ___________________________________________________________________________________