Dane. Designer.

Old Blog

An Acrobat Scripting Rant

I want you to know that it is quite hard for me to write his entry and not riddle it with profanity. Over the course of several months a hobby project of mine, something as geeky as a character sheet for the roleplaying system Silhouette, had me spending quite a bit of time with Adobe Acrobat’s built-in scripting engine, and I feel compelled to make sure you don’t repeat my mistake.

PDF’s are a staple of the digital pen and paper world, and yeah, the idea of a PDF character sheet makes a lot of sense over other more flexible solutions, such as an HTML file; most importantly because of the layout of course. To a larger degree however, I chose to experiment with Acrobats scripting because it seemed like a fun thing to do.

The thing is, while Acrobat does indeed have an almost full scripting language available for PDF files, it is in every way possible a usability nightmare and carries with it all the hallmarks of an alpha implementation.

First of all, on the whole process of writing code, there are largely no hotkeys (and assigning them through OS X doesn’t work). I hope you like your mouse, because you will be using it a lot to go to Advanced » Document Processing » Document Javascripts.... This is where your scripts live. And every single time you need to test your code, you have to close the editing window and any other miscellaneous sub-windows, all of which of course lock access to the rest of Acrobat while open. Oh, and these windows don’t disappear when you press Escape either. Hand on mouse, it’s the hard way.

Want to make another change? Advanced » Document Processing » Document Javascripts…, select file, find code bit, edit, save, close, close, refresh. Lather, rinse, repeat.

Script code can live in many different places in Acrobat, both in ‘files’ of a sort, each of which you access through the afore-mentioned Document Javascripts… menu point, as well as on any of the form elements in the document (and on each form element it can live in various parts of it, like under ‘validate’, ‘calculate’ or ‘action’). This sounds like a good idea in theory, right? After all it’s much easier to quickly plot in some JS for a button to make it work than it is to write the JS needed to assign said code to the button.

The problem is of course, that other than straight up forgetting what code you’ve assigned to a form element and having to fetch it through Advanced » Document Processing » Edit All Javascripts… you can also write code that assigns scripting functionality to those very same form element hooks. Except when interacting with form elements in HTML for instance, any such code is thrown out the window at the end of the session. In Acrobat you actually assign code to the element. It stays there indefinitely.

That would be a really good idea if it wasn’t for the fact that it’s pointless, as you can assign that very code on document initialization every time anyway. Now you have to deal with the fact that at any point if you assign code to an element, you have to remember to clean up after yourself, lest you want a nasty surprise down the road.

With the horror of the development environment in mind, I was very mindful to keep all my code in a single file. Until of course I hit about 1280-some lines and the internal editor croaked. There is no warning about this while you’re editing your code and there is no line-counter in the margin of the internal editor (which is nothing more than a text field in essence, which given that it doesn’t have line-numbers obviously has nothing as advanced as color coding, folding or any other sanity-inducing amenities). You’ll find out that you stepped over the limit when you’re unable to open the JS file again.

Of course you can create multiple JS files inside of Acrobat, but I never found out how to make them read each others global variables or even how to execute functions across the file-to-file gap.

So to consolidate all of the code into a single file, you can switch to using an external editor, which is better in many ways; using your editor of choice, which isn’t as 1981 as Acrobat’s, for instance. But… Acrobat opens the code in the your app and then waits in the background, beachballing until you quit the editor app again.

Yes, Quit.

It doesn’t check to see whether the file is being updated so you can keep your app open in the background; you literally have to quit the app, to activate Acrobat again and see your changes.

Madre de Deus.

And that’s just the big stuff. Then there are all the small things, most of which I’ve gladly forgotten; but just as an example, read-only elements don’t fire mouseover events. Because… Becaaaauuuuseeee. Who knows?! Acrobat has a built-in tool for copying out elements in a grid-like fashion; which is great for use with list-like forms and in my case needed in particular for the skill list on the character sheet. The tool however is utterly unconfigurable and names the resulting fields in the exact way I didn’t want them named (element names are read-only with code). Tabbing order? Forget about it. And if you want to chance it, you have to dragging form elements up and down on a list. I had over a hundred elements on that list (tabbing order is read-only with code). Code speed is sluggish to say the least, the documentation is bewildering and I have no real clue what exactly causes the code to be initialized.

And the list goes on and on and on.

Love it or hate it, Acrobat is an industry standard; I wish I could say the same for their scripting implementation.

I did finally manage to finish most of the ideas I had for the Silhouette character sheet—which I’m unlikely to ever actually use, but who cares—and it’ll take one serious pile o’ cash before I go back.