Mind / Matter
things that count
DN Logo



Click here to send an email. DN
Click here to send an email. SOK


-11545
200941
Why Postscript Sucks

This is another paper in the series of old comments relevant to some current issues.

I like Postscript and wrote a lot of it (by hand) over a lot of years. On the other hand it is sadly deficient in some respects, and we might learn something by looking at them. This paper was originally written in 1991 and an addendum was added in 1996. While some of my own commentary may indicate a change of mind on some issues, I think it is worthwhile to keep the original in it original state. At a minimum this allows us to understand our own growth.

DN Title Original Content Current Comment
Overview PS is the vogue printer control, page description, type-handling and (to a lesser extent) graphics language of the current day. It has had lots of favorable press. In some ways it is a very nice language. However, there are other ways in which it is a weak language, and perhaps something can be learned by discussing these weaknesses. In this note we will give scant attention to PS's many virtues. They have been written about already at length, and don't need repeating. I won't keep saying it, but it has to be remembered that this paper was written in the early 1990s, so discussions of `time' need to be interpreted in that light. In this case, history has supported that view.
Objective This paper attempts to do a number of things. First, some of the problems that are encountered using PS are discussed. Second, some of the characteristics of PS are compared and contrasted with those of a much simpler page description language. Third, some of the philosophical views that form the basis of the definition of the PS language are considered.
Problems There are several different kinds of problems presented by the PS language. Problems occur in the following areas:
  • World-view;
  • Conventions;
  • Scope;
  • Parsing;
  • Self-serving attitudes;
  • Implementation independence; and
  • Debugging.
World-View Problems with PS's world-view are the result of some confusion about who the language was designed to be used by. Discussing who is expected to write PS, and who is expected to read it, may shed some light on its design.
Conventions PS is not only a type handling graphics language. It also attempts to be a page description language, and it introduces numerous conventions in an attempt to shape a language otherwise devoted to syntax and semantics to this additional task. As might be expected this causes some difficulties, as conventions require testing and validation, and they may well be harder to test than rules.
Scope PS's scope is also the cause for some concern. As we will see, it attempts to handle problems in many different domains, and sometimes this can result in some of the problems being handled badly. PS is also surprisingly awkward in handling some problems that you would---at least at first glance---expect to be handled easily.
Parsing There are also problems parsing PS. It contains an extremely rich set of operations. This can be an important advantage in some cases. However, it can also make it very difficult to isolate and understand the effect of particular fragments of PS code.
Self-Serving There is also a hint of some self-servingness about the definition and implementation of PS. This is exemplified by the `Cost of hardware is falling (but in the meantime we'll sell it to you for a lot)' attitude that pervades a lot of PS discussions (and sales promotions). While I would argue that this point is probably still true, the availability of very high quality emulators, in particular Ghostscript, has mitigated this point.
Platform Independence PS is also implemented on a wide variety of platforms. Somewhat surprisingly, certain choices in the language make it difficult to provide implementation independence across this set of platforms.
Debugging Finally, debugging PS programs can be horribly difficult. The facilities available so far to help in this process remind me of those that I had to make do with in the earliest days of programming on the IBM650. For a rich and complex language, where mistakes are likely to be a part of everyday experience, this is an odd set of choices. The debugging facilities in PS proved to be about as weak as was suggested here. However, in practice so few people ended up by writing any `native' PS that it probably hasn't mattered much.
A Deeper View Let's take a look at each of these kinds of problems.
World-View PS is defined to be a rich language. The official Language Reference Manual that describes the language is more than 750 pages long. Within this manual the section entitled Operator Summary is more than 200 pages long. The appendix on page description conventions is about 100 pages long. That's rich. It can do a great deal. It is also very complicated. While it is possible to use the PS language to do some very interesting things quite simply, it can also take weeks, if not months, to begin to understand many of the available operations. It can take years to learn to use them well. Native PS proved to be such a complex language that very few people ever bothered to learn to program in it. The vast majority of PS ends up being written by drivers as an intermediate language that interfaces printers to various application code.
ASCII Base: PS has an ASCII based command language. That is to say that files full of PS programs are quite `readable' by the human eye. They consist of (near) English words and numbers, although since the items are presented in `reverse Polish' order---a language natural only to logicians and programmers of Hewlett-Packard calculators---so it takes some practice before it is easy to read them. Standard ASCII file editors can operate on---and modify---most files of PS code directly.
Audience: This raises interesting questions about world-view, however. Namely: Who did the designers of PS think was going to write it? And, who did they think was going to read it? I remember discussing this point with John Warnock at an early Seybold Conference in the mid-1980s. To my mind he wasn't very clear about an answer then, and over time I don't see any particular one as having evolved.
Some People: Certainly people occasionally do write PS code directly. Recently I've made a career out of it. However, the vast majority of PS that is written is surely written as output by other programs. For these programs, the human readability of the PS code is at best an irrelevance, and at worst an inefficiency.
Printers: Similarly, the vast majority of PS code is read by printers. Very occasionally, particularly when something goes awry, people have to look at their PS files, but again this is a relative rarity. For the printers, as well, the human readability is at best an irrelevance and at worst an inefficiency.
Why so legible?: So, why did the designers bother to make PS so legible. If it is not because we read it and write it so often then the answer must be so that we could edit and modify our PS files without going through any transformative filters that might otherwise be necessary. We would have to translate into and out of ASCII if the files were not already in that format. Alternatively, perhaps they just couldn't think of anything better. Let's assume, though, that they were more creative than this and that they did things for a reason.
Strange World-View: In any event, this seems like a strange world view. Expense is incurred all of the time in order to help with some relatively rare circumstances that could rather easily be dealt with in other ways. It is an example of the kind of engineering that makes one suspicious about other concerns and agendas, particularly when those doing the engineering also sell hardware.
Conventions Little of the PS language is devoted to the task of page description. The designers of the language decided that the appropriate way to incorporate the information necessary to allow PS to be used for this purpose was to establish a number of different conventions. Strictly speaking these conventions are not a part of the language, but they support the notion of a conforming document. This can be defined quite simply as a file consisting of PS commands and comments that conforms to the PS `DSC' (Document Structuring Conventions) specification. The manual uses a few more words:
A Definition: A fully conforming document is one that adheres to the following rules regarding syntax and semantics, document structure and the compliance constraints. It is also strongly suggested that documents support certain printing services.
It Goes On: This is followed by several pages of descriptions and rules. Needless to say, it is also a little confusing. Apparently a document can be fully conforming and not support `certain printing services' so their role in all of this is a little obscure. `Strongly suggested' is a phrase unfamiliar in most specifications.
Lots of Problems: There are lots of problems with doing things this way.
Comments: First, the notion that the designers of C, or any other general purpose language would resort to comments to do anything important is laughable. True, once in a very great while designers of a particular environment will establish a convention that will allow a comment on a first line of a source file of code to set some compiler switches (Apple did this with some of their early PASCALs), but this was regarded as a stopgap, and has been largely abandoned today. In most languages these days comments are comments.
Hard to Test: Second, it is extraordinarily hard to test whether we conform to these conventions in any very rigorous way. If I want to test if my FORTRAN program is syntactically correct I ask the FORTRAN compiler. Even better, I ask several different compilers, and make sure that I get consistent results across all of them. If I want to test if my C program is correct I ask the C compiler. If I want to test if my PS is correct, and all I care about is the PS itself, then I can ask any PS printer. However, if I want to test if my document is conformable, I can't. There isn't any `authority'. I can check out the PS parts of it with my PS printer, but it will just neglect all of the comments. The comments may be legal or illegal and right or wrong. Perhaps I won't know until something screws up much later in the process. Answering Is this a conforming document? is not an easy task. Apparently we need a person trained at scrutinizing these sorts of documents---familiar with all of the rules of conformance---to decide.
Enforcement: Third, the idea in the DSC standard of `requiring' that all pages be printable by just processing a prologue and the information that is bounded by the appropriate page beginning and page end comments is a difficult one to enforce, and quite prone to error. Perhaps I thought that I sorted out all of the necessary prologue, but unless I separately try to render each page on its own (and in all combinations!) I can never really be sure. Nothing in the PS language helps me with any of this. Indeed, the very richness of that language allows me to do all kinds of obscure things that would cause severe problems with this sort of rule.
Scope There are aspects of the choices about the scope of the PS language that remind one of the early days of PL/I when it was fashionable to make computer languages try to do everything for everyone. Like PL/I the real surprise is that given all that PS does, it is a wonder how badly some of the most important possible problems were handled.
Aspects: PS is a language that has many aspects. It is a:
  • Graphics language;
  • Type-handling language;
  • Computational language; and
  • Programming language;
Not String Handling: Strangely enough it is not a string handling language. Given that we are principally interested in describing pages, and that the majority of the space on most pages that are printed is composed of words, it seems to be somewhat odd to create a page description language that has built-in primitives to calculate arctangents, but no built-in capability to concatenate two words.
Odd Choices: Of course, it certainly is possible to write a PS program that can concatenate two words. Equally, though, it would be possible to write a program to calculate arctangents if that facility were not primitive in the language. One must wonder what was passing through the minds of the designers when they made this set of decisions. What problems did they think were the common every-day problems?
Not Typesetting: Perhaps equally strangely, PS isn't a typesetting language either. There aren't any facilities for doing hyphenation or any sophisticated form of line breaking. If this work is to be done, it is clearly supposed to be done elsewhere, probably in the software in prior stages of the preparation process that writes the PS as its output. However, if this is the case, then why don't we do some of the other less obvious stuff in this auxiliary software? This would leave more room in the PS world for those things that actually involve typesetting and rendering images of words.
False Claims: It should be noted that this isn't a criticism of PS unless it is sold as a typesetting or string-handling language. No one would (should) criticize COBOL for making elaborate mathematical processing hard. Similarly, no one would criticize FORTRAN for lacking easy string capabilities. But then, no one would ever sell either of these languages to do those things (anymore, at least!) that they are so inappropriate for. The same can't be said of PS.
Other Problems: PS also doesn't deal particularly well with some other problems that might well be expected to be handled in some relatively straightforward way. Examples of this are ligatures and kerns. Ligatures cause us trouble because PS fonts don't contain any structural description of the ligatures. In other words, in a PS font there isn't any description of the fact that the ligature `fi' (if it exists) is somehow related to the `f' and `i' characters. Since the font doesn't carry this information, it is hard to implement processes that convert the individual characters into the ligature. Further, if this task is performed by pre-PS software, then it can correspondingly be difficult to `break' the letters apart---should the typesetting circumstances demand it. While kerns are represented in PS fonts, they are also rather awkward to handle in PS programs.
Parsing Problems Given the complexity of the PS language, it is no surprise that the language is difficult to parse. In order to understand the meaning of any particular phrase or sequence in a PS program, the whole program up to that particular point must have been parsed and (at least in some sense) executed. The meaning of a particular phrase is not known until it has been placed in a context that is created by the execution of the whole of the PS program that appears before it. The PS phrase 3 5 add might well produce 8, but it might also well produce something else if add has been redefined in the sequence of execution before this particular phrase is encountered.
Locating Pages: Take, for example, the task of locating the `pages' of a document that is generated by the execution of a particular PS program. Why would we want to do such a thing? Perhaps to impose the pages on the paper in some order different than their generation, so that when the paper is folded the document will read properly. In typesetting this is called imposing pages in a signature. Or perhaps because we spilled coffee on a particular page and simply want to regenerate the obverse and reverse images of that one particular page. Or perhaps we want to merge pages from several documents that have already been prepared into one single document for presentation purposes. There are many reasons.
Look for Commands: A PS page is produced by the command showpage that transmits the current page to the raster output device, causing any marks painted on the current page to appear. Well and good. So all we have to do to figure out pages is to locate the showpage commands. The code between them builds the page and we can sort this all out. Right?
Macros might Interfere: Wrong. First, the showpage commands themselves are often contained in a macro that is expanded at the end of the page building process as each page is completed. Thus we must understand each definition in the PS program in case it happens, during execution, to emit a showpage command. Indeed, if we were more perverse we could make sure that the word `showpage' never appears at all by creating it as a string and then executing the string. Second, the marks that are placed on a page may be placed there by macros or called out of dictionaries. Again, this implies that in order to understand a page we need to have processed everything that went before it.
Economic Consequences: This has important economic consequences. If I want to build a simple Page Extractor program that would be capable of dealing with generalized PS, I have to create a complete PS emulator. If I want to build a program that will tell me which fonts are used in a particular document I have to create a complete PS emulator. Indeed, if I want to understand the contents of a PS file for any purpose whatsoever I really have to create a complete PS emulator otherwise the meaning of any particular part of the contents is unknown. Since PS is such a rich language, this emulator is large and creating it is quite a burdensome task.
Only Non-Conforming?: One might suggest that this is simply a problem with non-conforming documents, where we haven't included the correct comments. But as the above discussion of `identification of function by comment' suggests, this is a very weak strategy, subject to almost ceaseless difficulties in real implementations.
Alternatives?: But what are the alternatives? In a few moments we will contrast this situation with those found using simpler languages.
Self-Servingness It would seem that the engineers at Adobe who designed the PS language were not unaware of the fact that they would also be designing a lot of the hardware to solve the problems that their language created. They were thus in the position of (1) creating the mountain; and (2) getting paid to haul it away. In such circumstances no one would---or should---be surprised if they decided to create a pretty big mountain.
It's Business: Indeed, no one should be resentful of this fact. It's business. But then, neither should one be surprised if the economic trade-offs are made in favor in increasing their own income rather than being careful of the consumer's expense. PS may be the Cadillac or Lamborghini of page description languages, but if so it was designed for looks rather than for speed.
Need for Efficiency?: Throughout the history of PS its designers and promoters have always argued that we don't care how efficient it is, hardware costs are dropping so precipitously that no one will care. This is an understandable argument when it comes from people who make their money out of building the hardware. What is a surprise, however, is how many customers seem to believe it and pay high premiums in both money and effectiveness for facilities that may be only rarely used.
Similar Argument: It is worth noting that similar arguments have been made at every stage of evolution in the computer industry. Initially we weren't supposed to care how long it took to compile a program because hardware was getting so cheap it wouldn't matter. I first heard that argument in 1956. Thirty-eight years later we still care about compiler performance. Witness the number of benchmark ratings that are published every year, and the amount of effort that still goes into making compilers efficient. Perhaps the dismal failure of OS/2 to date is just an example of a place where this same argument didn't sell so well, although the case is unclear here because there are two dimensions of cost: `conversion' into the OS/2 world; and `execution' efficiency within it, that cloud the issue.
Where not Used: One might also note, by the way, that most CAD environments, where we have image intensive work, make little use of PS. While most of them can do so, the inefficiencies are so horrible that they almost never (at least in my experience) do. This suggests that some costs can be so substantial that they sometimes interfere with usefulness.
Implementation Independence Another surprise is the dependence of the PS language on real arithmetic. Surely one of the most important and painful computational lessons of the 1950s and 1960s was that the confusion associated with differing precisions in real arithmetic on computers would be a good thing to avoid. Yet PS makes heavy use of real representations, thus virtually guaranteeing that output will be rendered differently on different devices.
Knuth's Choice: Knuth, for example, chose a different alternative. In his typesetting work he determined that 32-bit integer arithmetic was implemented in a consistent fashion in virtually every computational environment extant. He then defined the scaled point as his basic print measure. He defined 1 inch=72.27 * 2^16sp. This makes one scaled point about five millionths of an inch. Since the human eye has trouble seeing less than one-two thousandths of an inch this is small enough to be beyond visible differentiation. Even the highest resolution typesetting equipment only resolves about 2500 lines per inch. Using 32 bits the largest measure is 2^(31-1) sp equals 32768 points. This is over 37 feet, and large enough for any typesetting purpose unless we are printing on the side of the Goodyear Blimp.
Integer Representation Knuth's integer representation is one part of a strategy that virtually guarantees identical treatment of all computations and all typesetting directions in all environments, down to the accuracy of the rendering devices themselves. With PS there can be no such guarantees. Since small differences in typesetting can cumulate in long documents, differences in real precision can eventually create visible differences that are easy to notice.
Knuth's Strategy: Indeed, to achieve implementation independence it is nearly necessary to publish the source code that correctly interprets the language. This is exactly what Knuth does with his typesetting software in the TeX Project. Using this strategy Knuth is able to create a high degree of implementation independence across all platforms. He enhances this with a test suite, especially contrived to provoke differences in implementation effects, if there should prove to be any, which is also published. Only after passing this rather rigorous test do we even make the slightest claim of correctness for an implementation.
Implementation Limits: Because PS is such a rich language it is also subject to an awesome number of limits, each of which may differ from one implementation to the next. Each of these limits provides an opportunity for a program to work in one environment and fail to work in another. There are always limits in any real computer system, of course, but with PS these limits may interact in such a bewildering way that the results are quite dumbfounding.
Richness and Implementations: One other point deserves to be made. Since PS is such a rich language it is also very difficult to get all implementations to behave in precisely the same fashion. Differences in implementation plagued the early days of PS and there is some evidence that they are still around. Indeed, this would be no surprise, as the richness of the language means that it is very difficult to write a definitive test that is likely to provoke differences in implementations if there are any.
Debugging PS is very difficult to debug. It is a rich and complex language and yet it is implemented principally on devices (printers and displays) that are hard to communicate with interactively. And debugging seems to proceed best as an interactive process.
Stack Orientation: The PS language itself affords little help in this process, and the very stack orientation of the PS world---a feature that allows a lot of the richness of the language---makes it notoriously difficult to work with when things go awry. Stacks make it easy to `bury' mistakes, and quite often a problem will actually show itself long after the mistake was really made because results will have been stacked and execution may have continued for some time.
Emulator: One possible way around this is to implement an emulator that can be used to execute the PS programs in a non-display, non-printer environment where interactive facilities are easily available. However, as has been argued above, the very richness of the PS language makes creating this emulator a formidable task.
For Comparison Only: An Alternative When we describe PS as a rich language we should be careful to note that the opposite of `rich' in this case is not `poor', it is `lean'. Perhaps we can learn something by comparing PS with a lean page description language, the DVI format as described by Knuth.
What is DVI? We should note at the outset that this DVI language only deals with a small part of the whole problem domain dealt with by PS. It doesn't calculate arctangents. It just places marks on paper, for the most part at simple right angles. However, here we are particularly concerned with the description of normal typeset pages, and the DVI language deals quite well with a large part of that domain.
Simplicity: DVI is a very straightforward language. Instead of the 740+ pages that are used to describe PS, Knuth manages to describe DVI in four pages. ASCII characters in the 0--127 range stand for characters in the current font. Knuth fills all of the character positions in every one of his own fonts so that they will not be filled in some non-standard way. Characters in the 128--255 range represent operations and functions. Some characters introduce font definitions. Others introduce the beginning and end of page blocks. Still others introduce font changes, rules and characters outside of the 0--127 range.
Operations: All of the DVI operations share some simple characteristics. First, many operations have a fixed number of bytes as an argument. The only other possibility is that the operation has an argument that tells its length, in bytes, and is then followed by those bytes.
Preamble: Second, all documents begin with a preamble, contain an arbitrary number of begin page/end page pairs (that surround the contents of the pages, of course), and are followed by a postamble, a font list and a post-postamble. The content of each of these building blocks is well defined.
Filters: This produces a situation that is easy for a programmer to handle. Thus DVI files can, and often are, manipulated by filters that operate on them to perform useful tasks. Handling the DVI doesn't impose much of a burden.
Easy Parsing: For example, a DVI file can easily be `parsed', either from the front or from the back end, and every page can be located without reading any of the intervening bytes. This is accomplished by having each beginning of page point at the next beginning of page. With direct access storage devices we need not read the intervening bytes unless we actually want to look at the information on the particular page.
Simple Rendering: The DVI file specification also requires that each page be fully renderable without reference to information contained anywhere else in the file with the exception of the font list that follows the postamble. It enforces this by not allowing any operations that would create a dependence on any aspect of the previous state. Thus given the font list (it tells us the codes used to encode all of the font shifts) we can go to any particular beginning of page marker and fully understand the page that is located there. All positions, rules, font changes, etc. are given in the commands that describe the page.
Contrast with PS: Contrast this with PS. Assume, for a moment, that we have a 1,000 page document represented in a file. If I want the 923rd page, I theoretically have to process the PS file from the beginning, setting---but not printing---all of the type on all of the pages until I get to page 923. With a DVI file, I have to process the font list, and then read through 922 direct accesses to successive beginning of page marker blocks, without doing any processing on these (skipped) pages. I can then render the page desired. The total amount of work that needs to be done is a very small fraction (certainly less than 1 percent) of the work that must be done by PS.
By Convention: Again, PS attempts to deal with this by having a convention that all pages are renderable separately if a prologue---which apparently applies to the whole document---is executed. What remains unclear is how this can be enforced, or indeed even tested, without a great deal of effort on the part of the software or people who are writing the PS.
Two-up Setting: As another example consider the rendering of a document that will have two pages set side by side in landscape orientation. Assume that it will then be folded into a brochure format. If I have a DVI file containing each of the pages of this document (typeset as though they are to appear on the left), then I can process the DVI file through a filter that understands the nature of the page imposition process and have it pull the pages in the proper order, and offset them in the proper way, to get a good copy of the document produced. With DVI this is straightforward, while with PS it is nearly impossible.
Conflict in Merged Documents: Finally, and here PS really seems to be in some trouble, consider merging documents by pulling pages in from different sources. It is not at all clear how the various documents should have their prologues executed, or about what is to happen if there is some conflict between the prologues. There isn't any similar problem in DVI. The only complex operation needed in merging information from multiple DVI files is to build a consolidated font table that can be used to represent fonts in the new document. Then each of the font changes in the pages that are merged has to be changed to the appropriate code from this new table. This is a trivial operation, and given the simplicity of the rest of the DVI file proceeds with only the simplest table lookup.
Correlated Work Knuth's DVI file format is robust enough to be used, quite naturally, in some other problem domains as well. For example, Knuth has implemented the notion of a virtual font in some of his typesetting software. In such a font each character is obtained by taking a mark from some raw font (i.e. one actually implemented in software or hardware) and placing it into the virtual font, perhaps combining it with other marks (to make accented letters, for example) or rotating it or moving it in some particular way (to get a vertical legend or label typeset perpendicular to normal text). The format for this is very much like DVI with very simple operators being mapped into ASCII character positions.
Robust This suggests that the representation chosen is quite robust. It also means that code that we develop for one purpose can serve as a good sketch of code that we develop for quite a different purpose. This conserves programmer time and energy.
PCL and Others There are alternatives on the DVI to PS continuum. Hewlett-Packard's PCL is one such example. Here we have a language which is nearly as simple as DVI (although not quite), but which adds a number of very simple graphics primitives and some type manipulation capability. In practical circumstances this may be a very good compromise between DVI and PS. Lots of CAD systems make use of PCL.
Not Superior: Notice, please, that we are not making any attempt to argue that DVI, PCL or any other such language is superior to PS. Each of these languages simply makes different choices about some of the necessary trade-offs which dominate the economics of page description. If one has a very complex image, with lots of rotated type and other kinds of graphics elements, then PS may be necessary even if it takes tens of minutes or hours to render the image of a single page. If one, on the other hand, has straight type and rules occurring only at standard 90 degree rotations, then DVI may well be enough.
Engineering Philosophy PS seems to have been developed with a philosophy that has attempted to preserve a huge number of options for the rendering of pages. In general, the preservation of options seems, at least superficially, to be a good idea. However, there is a lot of engineering evidence that suggests that the preservation of options beyond some reasonable point actually acts as a detriment to development rather than as an encouragement.
Second Systems Phenomenon: Perhaps this is at the core of the second system phenomenon that has been debated and discussed for years. Successful engineering projects often seem to be followed by dismal failures that attempted to generalize and build on the initial developments. CPM dominated the micro-computer world of the late 1970s, but attempts to `improve' it did not succeed in any great measure and it was over taken by DOS by the mid-1980s. The follow-ons to DOS/ have also been less successful than many anticipated. To this point in time, OS/2 has been only a very limited success.
Examples: The enormously successful and influential CTSS project at MIT was followed by the rather dismal failure of Multics. CTSS was built with equipment designed for a completely different purpose and developed under circumstances where new things were being learned every day. Nevertheless, it was a success. This was followed by an attempt to build Multics. It tried to do `everything' to provide options to application developers to do just about anything that they might want to do. The first time the `Hello' program ran it took nearly an hour to generate that simple message. So much generality had been preserved that finally resolving it into concrete terms was a huge burden.
Everything for All: Thus it is not good design to provide all possibilities everywhere. Doing so costs everyone something. The more buttons there are the more expensive they are and---even more important---the longer the time that we have to spend learning which ones to push. Good engineering design compromises the number of buttons down to a workable count. Enough are left to get all of the important work done, but not so many that they distract and add a burdensome cost.
A Question: At some time in the hazy future it would be interesting to know how much of the PS language was used and with what regularity. One wonders how many sines and arctangents will have been computed by PS machines in comparison with the number of that words will have been set. How much type will have been set at odd angles in comparison with the amount set at 90 degree rotations?
Constraints: Good constraints help engineers. They don't get in the way, and they guide the developments into economically effective paths. An unconstrained environment is often an invitation to waste and misuse. Though popular for a time, PL/I fell into disuse from just such problems. The costs of implementation were not recompensed by an environment providing useful help and guidance in practical circumstances. C has proven to be very successful for just this kind of reason. It is quite lean and simple in comparison to some of the more rich languages, but its very plainness allows developers to concentrate their efforts on the contents of their tasks, not on the forms of expression.
Tardiness and Success Of course, tidy languages show no particular signs of being successful. The most widely used natural language is perhaps Chinese, certainly one of the least `tidy'. The tidiest human language is probably Esperanto, and almost no one speaks that. Even given this, though, one would truly wonder if we sat a group down to design a good language for human communication---with no holds barred---and they were to come up with one as complex as Chinese.
Close PS may be cream that has risen to the top, but perhaps it's time for a diet. On the other hand, it's hard to resist a little cream from time-to-time.
Addenda - 1996 What follows are some addenda, added in 1996 without changing the prior content of the document above.
PDF PS is directly linked with Adobe's somewhat newer Page Description Format (PDF). PDF was designed to allow more effective structuring of pages in an attempt to deal with some of the criticisms that are made above. In particular, PDF enforces some conventions on the PS code that generates the pages. For example, each page must be independently renderable without any reference to any other page. Pages are also encoded as a rather elaborate structure of objects that can be located through a table that appears at the end of a PDF file.
Suggested Follow-Up: After PDF has been in use for a while, it might be useful to perform an analysis of this language much like that we have presented about PS above. There is much to say, as many choices have been made in PDF, but it might be better to wait until we have a little more experience before we comment in detail.
Encoding: It is interesting to note---as a peripheral issue---that most PDF files are circulated with (at least in my experience) encoded PS segments. This could be interpreted as at least a casual admission that some form of encoding is often a good idea. In its earliest test versions, PDF files were essentially all ASCII, but in later versions this gave way to LZW encoded PS fragments.
On Choices of Scope It might be useful to spend a little time thinking about the choices of problem scope for PS. One way of thinking about this is to consider the prospects for letting PS and the printers deal with all of the issues associated with type `measure' to the extent that this is possible. While we might well want our higher level software to make decisions about the broader aspects of type placement on the page, it would be nice if this higher level world didn't have to pay too much attention to the details of type size, ligatures and kerning. While it is quite clearly possible to have either the computer or the printer worry about such things, if both have to worry about all of them, we sacrifice some potential economic advantage, and at the same time we afford the opportunity for nattering disagreements in detail to creep into our situation.
Visible Results: For example, there are very subtle issues about character placement and character scaling which come into play when type is actually rendered on printers or screens. Pixels seem to be small when we look at them individually, but when we look at the effect, for example, of the cumulative placement of characters on a line, tiny differences can produce highly visible results.
Being Driven Crazy There is also a perplexing issue associated with the differences between PS drivers that can be encountered in a complex environment---for example Windows. While we might naively expect a particular piece of code to generate PS output that was identical irrespective of which of several PS drivers was being used, this is almost never the case.
Printer's Capability: To some extent this is unavoidable. Different printers have different capabilities, and ultimately this must be reflected somewhere in the interpretations generated by the drivers. As a very simple example, consider PS commands that might control feeding paper from more than one tray. Such commands are useful and important on a printer with more than one tray, but have no meaning on a printer with only one tray. As a result commands that control this kind of function exist in a sort of PS nether-world, between the `official' language as described in the Red Book, and the realities that are described in the manual of PS addenda that accompany each individual printer.
Differences: At the moment I can find no clear description of kinds of things that might differ from one driver environment to another. Complexities abound. Some drivers may make assumptions about fonts---much deeper than just issues about font names---which are appropriate for some printers and inappropriate for others. I have seen real circumstances where three different drivers---all purporting to be faithful to true PS, each produced different results when the items were actually printed. The differences in this case were generally due to assumptions about character names, character widths and character mapping. However, I am not sure if there are other dimensions that also might cause similar problems.



© Copyright 2003 David Ness.
Last update: 2003-05-24 16:09:41 EDT