Page Duplication with Adobe Acrobat and JavaScript

This is a script that I wrote a few years ago for my previous job. I worked in the printing industry, and we were making the transition from a popular imposition tool to one coded by an in-house development team. During the change, we lost a feature that was rather important to those of us running production: the ability to rapidly duplicate pages within a PDF file. The new software did not yet support it. This functionality is useful when creating tear-off pads and carbonless forms, among other things, and – needless to say – the disappearance of this feature did not mean that the jobs which required it vanished, too.

My solution was to automate the manual process that we had to use until something better came along: extract a range of pages to a temporary file and then reinsert them into the main PDF file as many times as required. For pads of 100 pages, this could get quite tedious.

I was able to put together the script below and install it on our computers about a month before we finally got the feature from our in-house development team. I still use the script at my present job, and it is my thought that perhaps it will be useful to other professionals in the printing industry who find themselves without the ability to quickly duplicate pages within a document, or who would rather do so from within the PDF document (our developers insisted on making the tool external to Acrobat). That this can be done at all is a testament to the wisdom of including a scripting language within your project. To my knowledge, Adobe has not yet implemented a page duplication feature as part of Acrobat – but we are still using Adobe CS4 at work, and I only have CS3 at home, so...who knows? Continue reading...

Causerie: A Wishlist

Previously: Causerie Begins With...

When beginning a project, after you have decided the goal, it is often helpful to brainstorm a list of ways in which the goal will be fulfilled: a wish list of features. The advantages are many: it helps you to chart your course – how you will achieve the end result, it provides focus, it can be used to delegate tasks, and so forth. The danger is of feature creep: that you will add so many features that your project becomes mired in wishes before it even begins.

To prevent just such a thing, my first wish is that the project remains manageable by a single person, if need be; otherwise, it will never see the light of day and any other features that I'd like to add will be moot. Features that might require the investment of another developer – or a whole community of them – are best left until after the first release. After all, how do you attract a community of developers if you can't prove the thing works? This doesn't mean that you can't wish for the moon when developing a wishlist of features, only that you might have to accept that you must first build the rocket to reach it.

The following wish list will make more sense now that the appropriate background has been drawn for you. The list represents the things that I would like to have in the language; these are not all necessarily features that will be added – and if they are, they may not all be added for the first iteration of the language – but it provides a good starting point. It will help to define the design of the parser and executor back-ends. And so, without further ado, the list: Continue reading...

Arena v1.0

Rambling Preamble

arena can probably be called a content-management system, in that it manages content for a website, but that title sounds grandiose given that the overall goal for arena was to be a simple and elegant intermediary between the content of a website and the layout of that website. That likely sounds no less grandiose, but it does mean that arena could be called a blogging tool, or a tool to create and manage forums, or a way to display information from a database, or nearly anything else.

As with any good content-management system, arena separates the content of your site from its layout. You can change the text of a given web page without rewriting the HTML that makes up that page; in fact, you do not need to know HTML or CSS or JavaScript at all in order to create content for your site (some familiarity with Markdown is helpful, however). You can likewise change the layout of your site without the need to re-flow or manipulate the content to fit into the new design. arena will generate the appropriate code.

The overall design goals of arena are always simplicity and elegance. Simplicity means that the code is tight and efficient; speed trumps size. The code does no more than it needs to do, but it is flexible enough to leave room for expansion. Absolutely nothing is hard-coded.

Elegance means the code is easy to read, and so is the solution created by that code. The Markdown syntax for posts was chosen because it fits both criteria, and so integrates nicely with overall tone of arena.

It is for the above reasons that arena is coded in Python, even though it existed in PHP in a previous incarnation. I disagree with some of Python's design quirks, but overall the scheme provides for code that is both simple and easy to read, whereas PHP tends to get messy like C++ gets messy – unless you're very careful. Additionally, because the result of compiling every script is saved, Python generally performs faster than PHP (except where tools such as the Zend Optimizer are incorporated – but the last host I used did not have such a feature enabled, and it is built into Python).

Disavowal and Disclaimer

It is worth noting that, although I am documenting arena and making it available to the general public, I will not provide support for the code! You use it at your own risk. arena is a means to an end for me, and while I'm happy if it helps other people, I have other goals to achieve, of which arena was only a first step. I expect that, if you intend to use the code, you will have more than a passing familiarity with Python or you will be willing to learn in a trial by fire if such a thing becomes necessary. If you are thoughtful and careful, however, you should be able to get arena to do what you want it to do; the code is flexible enough to allow for additional features to be added without breaking everything.

Don't get me wrong, though: I would like to hear about your experiences with arena, and may consider your really good idea for an additional feature, but unless it's a major bug that threatens a catastrophe of dinosaur proportions (either an extinction event or a Jurassic Park event – take your pick), I expect that you will figure out the problem without me.

Continue reading...

Causerie Begins With...

Previously: Adventures in Computer Linguistics

On reaching the conclusion that writing a computer programming language is the only thing left to do, the next logical question is: where to begin?

Is and Isn't

Well, think about it: what is a computer language? What is a program? From the computer's point of view, a program is simply a sequence of modulated voltages. At a slightly higher level, these are the 1s and 0s that make up the binary code which the processors use to execute instructions. It is undoubtedly possible to program a processor using differential voltages, but it is slightly easier (for a twenty-first century human) to send it a sequence of 1s and 0s – and even easier to represent those 1s and 0s as something with which the human is familiar, such as English (or Spanish, or Portuguese, or whatever language you happen to speak). It gets even easier if the syntax of that language – the rules about how it should be written – more closely match the syntax of the language that the programmer writes (and speaks, one would presume). Continue reading...

Adventures in Computer Linguistics

Obligatory Disclaimer: Where I provide links to languages as examples of my own experiences with those languages, it is best to keep in mind that these have been my experiences, and the opinions I express about those languages are my opinions. Your mileage and conclusions may vary.

Why create a programming language? There are already any number of languages available; surely, among the myriad available languages, there is at least one that will satisfy the purpose of a given programmer, whether that is for greater fundamental control over the computer, improved structure and readability of code, or the quick translation of an idea to an actual process. Yet, when perusing the lists of available languages, it becomes clear that many of them are limited in some way: some of them have highly-specialized use cases, some of them are limited to a narrow band of platforms, and some of them are not yet feature-complete. Moreover, when attempting to use some of these languages, one may find the syntax disagreeable, the documentation limited or incomplete, or the developers removing functionality in order to conform to the standards of the language as defined by a major corporation. Each of these languages may satisfy a particular programming requirement but, in trying to find one that I could use in order to write my game engine, I found not one of them which could satisfy me. Continue reading...