[Tfug] Scripting PDF's

[Bexley Hall]

Hi Louis,

On 7/10/2013 9:21 AM, Louis Taber wrote:
> I have used pdftk (.pdf tool kit)  It is a burst-er, stapler, rotator,
> extractor command line tool.  It is in the Debian packages, so either it is
> a different version or ???
> http://packages.debian.org/search?keywords=pdftk&searchon=names&suite=stable&section=all
>
>>From http://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/
> "PDFtk Server is our command-line tool for working with PDFs. It is
> commonly used for client-side scripting or server-side processing of PDFs.
> It is also used by OEMs and ISVs to give their products the ability to
> manipulate PDFs. A commercial license is required to distribute PDFtk with
> your commercial product."

Yes, it's been in the pkgsrc collection for ages (I've used it
alongside psutils).

But, in this context, "scripting" is being used to refer to
the scripting of actions that manipulate the PDF document.

In *my* case, I want the code (script) to run *inside* the PDF
to script the document's response to the user's actions.  E.g.,
I should be able to prompt the user to "type in" a sentence
and then generate an audio rendering of that sentence on-the-fly
for him/her to evaluate some aspect of the speech synthesizer that
I've embeded (scripted) into the PDF.

Or, let him "draw" a figure and have a recognizer scripted *into*
that (different from the example above) PDF tell the user what
it thinks he has "drawn".

I rely heavily on PDF's to document my code base (I've probably
got more than 1000 pages of PDF already).  There are just too many
issues/concepts to explain to the "developer" in source code
commentary.  Instead, I pull all that into a formal document (PDF)
that acts as a tutorial explaining the issues and ideas that I
rely on in the actual software.

But, it is difficult to cover every possible example explicitly
in such a document.  Instead, I want to state my generalizations
and give the user a means of empirically exploring each of these
*other* examples interactively.

For example, a necessary condition for a loop to exist in a
cubic bezier if for the control polyline(gon) to resemble an
"X" (i.e., the first and third segments must intersect).
But, this doesn't *guarantee* the creation of a loop.  I
can (and do) explain algorithmically/numerically the conditions
that *will* guarantee a loop (or even a cusp) but it is far more
instructive if a reader can play with a demo *in* the PDF that
lets him alter the control polyline arbitrarily so he can see
how/when loops form -- instead of just relying on a mathematical
proof (that the *software* relies upon!).

[I.e., the commentary in the source code simply references this
assertion/fact that it expects the PDF to have clarified for the
"developer"]

--don