[Tfug] Scripting PDF's

[Bexley Hall]

Hi Robert,

On 7/10/2013 4:18 PM, Robert Hunter wrote:
> That's a pretty tall order, Don.  I don't think any such beast exists, at
> least the way you've described it.

If it doesn't, it *should*!  :>

Actually, I think I may have found a way of doing the "drawing"
stuff ("draw an X") -- but, it appears there is a bunch of *other*
stuff I will have to learn before I can try my idea... :<  (crap!)

The challenging problem will be the speech synthesizer.  I can work
around the performance issues by rewriting the code to *buffer* the
audio it generates (instead of generating it on-the-fly) at the expense
of a lag between "click to play" and "sound available".  I think this
would be acceptable to a user/reader given the fact that the sound
would be so closely tied to the description of the controls that
affect it (this assumes the JS is *interpreted* and not JIT'ed).

But, I am not sure it is possible ("legally") to create a dynamic sound
object and then pass *that* to the "player"!  :-/

[I am spoiled by my heavy reliance on pointers in the way I code
things... makes it really easy to move things around!]

> However, web-based media is probably as
> close to a universal delivery format as you're going to find.  HTML5 would
> obviate the need for Flash.

But, would it let me bundle everything into a single (non-archive) file?
E.g., PDF's let me toss the video, images, sounds and code all into a
single "container".  I can even attach "source.c" so the user/viewer
can have it at his disposal (even though the text of source.c isn't
visible *in* the PDF).  That level of convenience is *really* cool!
By contrast, having to bundle a bunch of random files into an
archive/folder to do the same thing...?

> But the processing requirements you described
> seemed a little heavy for a typical Javascript environment.

Dunno.  Hence the nature of my "scripting PDF's" query!  As I
said in my initial post, the examples I've seen on the web have
all been "trivial" -- "scripting *forms*":
    if expenses > income
       then net_income = 0

> Perhaps
> server-side processing would help.  Or, maybe you should just write your
> own stand-alone application, and benefit from the level of control, and
> processing capabilities it would give you.

There are several problems with that approach.

First, for which hosting platform do I write it?  Do I have to write a
version for user's who want to read the documentation on a Mac vs. PC?

Second, what can that application *expect* it's interface to the system
(and, ultimately, the user) to be?  How does it access the audio
subsystem?  Display?  Pointing device?  What happens when Windows 999
is released...?  Goobucktwo 87??

Third, it breaks the connection between the description and the
"exploration" (demo) of that topic.  You can't just read about
how "glottal opening" affects "breathiness" and *try* varying that
parameter to hear the the affect!  Or, how vocal tract length
affects the number and range of formants that can be accommodated
(male/female/child).

[I tried to develop this codebase using LP tools but quickly
grew frustrated with that!  It gets in the way of coding *and*
documentation!  I'm hoping the approach I've now taken is a more
modest and usable one.  *And*, the documents themselves have value
as free-standing entities without any reference to the code!]

Fourth, it requires keeping multiple objects together in distribution
(document, application(s), etc.) AND *in sync*!  ("Hmmm... why doesn't
the breathiness parameter seem to work?  Ah, this is the wrong
version of the app!")

The first two of these speak to wanting a "virtual machine" in which
to craft the applet.  Something where you can be assured the applet
will continue to work from OS to OS, platform to platform.  The last
two speak to wanting a "container" that can carry everything related
to the "presentation/demo/tutorial" (plus other cruft of interest)

> On a different subject, I wanted to suggest that when you have these types
> of questions, it would save a lot of misunderstanding, and waste less time
> if you would state up front what it is that you are trying to do, and what
> your requirements are.  You obviously have pretty clear picture of what you
> want.  Just state it in the first email, instead meting it out one email at
> a time, and possibly annoying a bunch of people in the process.

Well, I'm sort of damned if I do and damned if I don't, eh?
I write a lengthy post and folks complain "it's too long to read".
Instead, I abbreviate my post to *exactly* what I want:

    Anyone have any first-hand experience scripting PDF's?
    Search engines don't seem to offer up much by way of
    assistance (besides the obvious "scripting of forms").

    On a related note, any comments on how well/poorly
    the non-Adobe "readers" handle these more esoteric
    PDF capabilities?  Which ones to explore; which to avoid?

*I* don't think there is any ambiguity, there.  It doesn't
say "scripting the GENERATION OF pdf's".  And, shows my
interest lies beyond the "scripting of forms".  I.e., if
you don't know what a scripted form is, then you probably don't
know what I'm asking!

The second paragraph emphasizes that these are capabilities of
the *PDF* (i.e., the *format*), not something external to the
documents -- because it suggests that other readers (e.g.,
FOSS) will probably *not* be able to handle these capabilities
as Adobe's products will.

I think the problem lies with folks misunderstanding the
subject and not carefully reading what I have *literally*
asked (and, if I rephrase it many times to minimize that
misunderstanding, then I'm too "wordy"  :< ).  "Read what I
*wrote*, not what you *think* I wrote."

      Paris
     in  the
   the  Spring

It's also probably less likely to find folks doing these things
with FOSS tools because those tools probably *aren't able* to
do these things!  (i.e., what PDF creation tools are there?
do they even *mention* how you embed JS in the PDF's that they
create??)

(sigh)  Can't win.

> This project you are working on sounds very interesting.

<shrug>  *I* think it is.  :>  I suspect (hope?) the last "big"
project I'll work on...

> I would love to
> have a look at the code.  Is it on github, or somewhere I can see it?

No, I don't let code off of my development machines until it is
released.  That gives me more control of how it evolves than if
I let folks (clients, users, etc.) go poking at it before it's
done (clients and users usually know very little about "what they
want" -- though they never hesitate to tell you what they *don't*
want!)

Just going through the geometry and algebra was tiresome...  I'm
not used to thinking along such "structured" lines since school!
<frown>  E.g., what's the geometric basis for de Casteljau's
algorithm?  Why does it work?  (instead of just blindly *accepting*
that it works!)  How can that be exploited to compute curve length?
How do degenerate curves affect those algorithms??

I'll email you this PDF once I sort out the "interactive" stuff
so you can see the "value" that (I think) such a document can have
towards "educating" someone who will have to use or maintain that
aspect of the codebase hereafter.  I *think* it will make it *much*
easier for folks to *quickly* grasp ideas that would otherwise
be very tedious and "dry" to explain with just static words and
pictures!  I.e., see how quickly *you* end up saying, "Yeah, that
makes sense..."

At the very least, you'll get a better idea for the level of detail
I put in my documentation!  :>

--don