AppleScript is a terrific tool for prepress

This entry originally appeared on What They Think in February, 2011.
A few years ago I wrote a small book called Beep! It’s about AppleScript. That book, now in its fourth edition, has never been printed on paper. I use it in my classes, and I have loaned it to other teachers who use it to teach very basic AppleScript programming to people who want to jump into programming, but want the happy-face version. I have never published it on paper because I keep changing it, and change is a curse when you must go back to press. The other reason I have never printed it is that I am a cheapskate, and printing costs money, while a PDF file costs (apparently) nothing.

For those who think that programming is an art, AppleScript can be as rewarding as any other programming language, and it’s slightly easier to learn than C++ or other high-level programming languages. It’s important to remember that all programming languages require a discipline that most of us don’t have. Programming languages are intolerant of error in grammar or syntax. They are strict and sometimes opaque – meaning that the solution to a problem is not easily discerned. Programming also takes patience and time, rare commodities in a prepress environment.

OK, now the disclaimers are stated, let’s see how you can use AppleScript in a prepress and printing environment…

Each year I assist in the production of a printed (printed!) directory of merchants and business people in our community. It is published by the local Chamber of Commerce. The Chamber maintains its member database on a Windows PC, and the application is unknown to me. Each year they generate the output to be published in two forms: pure alphabetical and category-then-alpha. This is so there is a cross-reference in the book.

Accountants come first, and within Accountants, Avery is first, followed by Charlesworth, etc. I use the same data for both listings, omitting any information that is unnecessary in the process.

The data come to me with markings that we agree upon, and sorted by the Chamber in the order they want. Problems occur with company names like !excitement (which starts with an exclamation mark) and 20-20 Marketing, which always sorts to the top, but doesn’t always belong there. The markings are possible in their database system, and they are reliable for me to use as search strings in my AppleScript programs, which I use to change things into printable styles that are use in Adobe InDesign.

Here is a key fragment of my AppleScript, which I run with an excellent text editor called Tex-Edit Plus, as it is applied to their database output:

 replace window 1 looking for return & "[#C]" replacing with return & "<pstyle:Category>"
 replace window 1 looking for return & tab & "[#O]" replacing with return & "<pstyle:Company>"
 replace window 1 looking for tab & "[#M]" replacing with return & "<pstyle:Principal>"
 replace window 1 looking for tab & "[#A]" replacing with return & "<pstyle:Address>"
 replace window 1 looking for tab & "[#P]" replacing with tab
 replace window 1 looking for tab & "[#Z]" replacing with return & "<pstyle:Address>"
 replace window 1 looking for tab & "[#F]" replacing with tab
 replace window 1 looking for tab & "[#E]" replacing with return & "<pstyle:Email>"
 replace window 1 looking for tab & "[#W]" replacing with return & "<pstyle:Web>"

The bracketed tags are the agreed-upon tags output from their database. The <pstyle:> tags are those acceptable to InDesign. Like other styles, these tags only identify the style to apply to the text that follows. The actual definition of the styles occurs in InDesign.

And, there is the beauty of the process. The styles (color, fonts, sizes, alignment, etc.) can change from year to year, and the style names (and my AppleScript work) can remain the same. So, the content is consistently prepared (I wish this were true) and the styles can be changed at the whim of the designer.

The nice thing about building the AppleScript is that it can take a file with hundreds or thousands of entries (this is a small city, so ours listings are small) and process them in about five seconds to make the database printable. I admit that I am constantly modifying the AppleScript to accommodate problems in the database files. There are occasional errors in the database records, but in the end the process saves hours and hours of hand work.

The hours and hours I spent creating and correcting (debugging) the script pay off in savings in the long run.

Addendum for August, 2011: This year the Chamber of Commerce has changed design agencies to do the production, and that agency has changed the style of the listings, which will require me to modify not the basic function, but the order of my AppleScript. I have looked at the new format, and I have a scheme in mind for processing the data this year. But I won’t tackle that until later in the summer.

 

About Brian Lawler

Brian Lawler is a Professor of Graphic Communication at California Polytechnic State University, San Luis Obispo. He writes about graphic arts processes and technologies for various industry publications, and on his blog, The Blognosticator.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.