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 : [email protected] / 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
___________________________________________________________________________________
