Chapter 3

Foundations

This chapter presents some fundamental concepts for programming in PostScript. Some of the information may seem extremely introductory and perhaps carried over from other languages, but there are many tips and techniques presented that should benefit even the seasoned PostScript programmer.

The chapter starts with a basic paradigm of program development that will serve as a foundation for developing PostScript programming skills. This paradigm is certainly not the best or the only approach to constructing programs, but it may help even to contrast the steps with your own thoughts on software development.

There is a cyclic pattern to all kinds of program development, although it varies considerably based on the tools and the environment in which you are working. To build the PostScript programming paradigm, we will look at the sequence of steps involved in learning to develop software in a new language or on an unfamiliar system (see Example 3.1). The list may

17

seem a little light-hearted in places, but is an attempt to accurately identify the learning curve and problem areas that real people encounter.

Example 3.1: The Programming Cycle

1.Get a trivial “Hello world” example program working, proving to yourself that the basic system is working correctly, your documentation isn’t lying to you, and that it is possible to construct a working program in your environment.

2.Excitedly type in a one-page program that you designed on a legal pad, and attempt to get it to work. At this stage it is difficult to tell why your program isn’t working, because it typically just doesn’t do anything, so you have nowhere to start in debugging it.

3.Find some simple oversight that caused your program not to work, like the lack of a begin or a %! or something trivial.

4.Develop a skeleton program, either in your mind or in a file, that has all of the basic ingredients necessary for a working program, based on the lessons learned in Steps 1, 2, and 3.

5.Develop several small, useful, working programs using some of the basic language constructs you have learned.

6.Attempt to tackle something bigger, or a new language construct, but with a solid foundation on which to test and debug.

7.Get confused by the documentation for new language features, causing the program to become buggy. Learn some ad-hoc debugging skills based on your frustration in finding the bugs in your program.

8.Go back and read the introduction to your documentation and learn that your basic model of the programming language was slightly incorrect. Adjust your thinking accordingly.

9.Create an entirely new skeletal program and get it to work.

10.Be inspired by your new, working program and begin to think of features to add.

11.Develop a rough working feature, inventing procedures, variables, and interfaces as you go.

12.Attempt to fit the new feature into the skeleton of your working program; readjust the basic framework slightly to accommodate it.

13.Test the new feature, and discover some bugs, some related to the basic workings of the original program.

14.Debug the new feature thoroughly, getting it to work well with the existing program.

15.Go back to Step 10 and repeat through Step 15 indefinitely

Steps 1 through 9 in this list represent the learning curve for a new language or system, before you have become comfortable with the process. Steps 10 through 15 comprise one view of the basic software cycle for a single-person programming project (without a lot of advance planning, which is typical of most programming projects).

The software cycle is very important to consider because it very much affects the quality of the programs you write. You may adopt techniques during your learning phase that lead to very poor quality programs, but you may not even know it. You may introduce fundamentally bad design or deeply-rooted bugs during the development process that could have been prevented had you designed the entire program at the beginning, or if your techniques had been sound enough to prevent cancer in the core of your software.

Good programming skills will make your PostScript programming task much more successful and enjoyable. Some of the techniques presented in this and subsequent chapters should strike a chord with you and help you to develop a sound methodology of your own.

POSTSCRIPT LANGUAGE SYNTAX

One of the first problems that beginning programmers encounter when learning a new language is how to get the basic syntax right. It seems trivial once you get past it, but the first step always is learning how to represent strings, how to divide two numbers, how to find mismatched brackets, or any of the other details involved in getting a simple program to work.

In order to write good, solid programs, it is important to understand the syntax of the language well enough that you can write legal, working code instinctively, without hesitating about whether you need a slash, a backslash, parentheses, or curly braces. Luckily, the rules for PostScript syntax are pretty straightforward and easily remembered. Rather than providing an exhaustive review of the language syntax and representation, the following section presents some “seat of the pants” rules that should