[NTG-context] PDF viewer poll

Hans Hagen j.hagen at xs4all.nl
Tue Oct 15 10:11:05 CEST 2019

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 Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl

More information about the ntg-context mailing list