Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!lll-winken!sun-barr!newstop!sun!imagen!daemon
From: ib@apolling (Ivan N. Bach)
Newsgroups: comp.lang.postscript
Subject: Re: PostScript Language
Message-ID: <9457@imagen.UUCP>
Date: 27 Feb 90 06:40:20 GMT
Sender: daemon@imagen.UUCP
Lines: 146

There have been several emotional responses to my recent posting about
the deficiencies of PostScript, but nobody disputed my claims by 
offering some technical counter arguments.

So most of you seem to like PostScript, and you think that one of its 
best features is that it supports only a readable format.  You describe 
PostScript as it was some new version of BASIC or LEGO, and you like to 
code in that language. 

The only problem is that PostScript was not designed for that purpose,
and most of the time it is not used the same way as, for example, BASIC.

John Warnock described PostScript as a "hidden layer" between a printer
driver and a printer.  Most of the time (99.99% of the time) people are 
using desktop-publishing applications, such as PageMaker or Ventura-
Publisher, to indirectly generate PostScript.  They are not directly 
writing PostScript code.  When you request a printout, the application 
calls a driver for your printer, the driver generates PostScript code, 
and PostScript code is sent to a PostScript interpreter or stored in a 
file.  Most of the time PostScript code is automatically generated, 
interpreted, and discarded, without ever being seen by a human being.  

Sometimes PostScript is transmitted to another computer, or to a 
remote PostScript printer.  Only occassionally somebody looks at the 
PostScript code because something goes wrong, or an adjustment has to 
be made, and that adjustment cannot easily be made by using an 
application program.

The fact is that the readable format is NEEDED only when you have 
to manually change or debug a PostScript program, or when you have to 
transmit it over a communications channel that does not transmit 
binary data reliably.  To insist that a readable format is needed all
the time is like insisting that all computer applications should be
distributed in a much longer, debugging version that preserves the 
line numbers in source code, because somebody someday may want to 
debug them.

Have you ever stopped to think why do you have to code directly in
PostScript?  Most of the time the problem is that an application
does not give you access to the full power of PostScript, and the
only way you can achieve a particular special effect is to code 
it yourself.

If PostScript was used only by a small number of people, I would 
understand your lack of concern about how efficiently page descriptions
are encoded in PostScript, and how the efficiency of PostScript
compares with other methods of encoding the same data.

I have to remind you that PostScript was proposed as the ONLY method
for encoding page descriptions in all countries of the world, because
that will facilitate the transmission of page descriptions to remote
computers and printers.  When you propose a new world standard for
storing and transmitting image data, you may want to check the
efficiency of your encoding, not to please me, but to avoid wasting
billions of dollars.

Let us assume that there are 1,000,000 people in the world who use 
PostScript, and that each person on average wastes 1MB of disk 
storage and 1 hour of time each year because of inefficient encoding.
The total waste would be huge year after year.  I think that the
actual numbers are much greater, and growing each year.  Not to
mention the Kanji version of PostScript.
    
I find it ironic that the users of USENET, who are used to the 
warnings about wasting the bandwidth on our network, do not seem to 
be very concerned about the efficiency of PostScript.

Just how inefficient is the PostScript readable format?  I had the
opportunity to compare page descriptions in PostScript with the
corresponding page descriptions in a language that supported both
a readable and binary format.  Depending on what kind of statements
you use, and how many bytes are taken by comment statements, you
can reduce the number of bytes needed to encode a given image by
as much as 90%.  You people are telling me that this does not
matter, and that the fact that PostScript supports only a readable
format is of minor importance.  

It is true that a PostScript program is usually more compact than
a bitmap that can be produced from that code, but nobody can tell
me that a statement such as:

    /Helvetica-BoldOblique findfont 20 scalefont setfont

is the most compact way of specifying that you want a particular
20-point font.  What do you think a PostScript interpreter does
with these long names as it scans the input stream of characters?  
It immediately replaces them with more compact codes.

Some of you suggested that I should simply pay more if I wanted
to transmit page descriptions faster.  That is like saying that
I should simply buy more gas if the engine in my car is not
designed to be very efficient.  I was hoping that at least some 
people from California would be concerned about unnecessary wasting 
of scarce resources.

There are many programs which can be used to compress PostScript
code.  The problem is that such code cannot be transmitted 
directly to a PostScript printer.  You have to implement some
program or device at the printer side that will decompress the
PostScript code before it is sent to the PostScript interpreter. 

Some of the QMS interpreters accept a binary format just as
easily as the corresponding readable format.  You do not have
to specify any options or set any switches.  You just send
your code to the interpreter in one of the supported formats.
By default, the driver for a PostScript printer should generate
PostScript in a compact, binary format.  The driver should
generate PostScript in a readable format upon request.  A couple
of years ago, I implemented such a feature in one of my Windows
printer drivers.

Which binary format should we use for PostScript?  It could
be proposed by Adobe.  I understand that Adobe already uses a
binary format in its Display PostScript.  Alternatively, we
could design an efficient binary format in this newsgroup and
submit our proposal to the companies which have developed 
PostScript interpreters.  We could implement the proposed 
format in the QMS UltraScript interpreter to see how it works.

I think that it is about time that we make a substantial contribution
to the PostScript language in this group, instead of quarelling 
about less important things.

When we finish designing the PostScript binary format, we could
design the user interface for an application like the Adobe
Illustrator that will give us access to the full power of 
PostScript.  Then we could implement such an interface under
Microsoft Windows, OS/2 Presentation Manager, X windows, etc.

We should also do something about the executive or interactive
use of PostScript.  Have you ever tried to use a PostScript
interpreter in interactive mode?  Most user interfaces for this
mode are worse than BASICA.  You cannot load a PostScript program,
submit it for interactive interpretation, edit it, or resubmit
it the way you can do that with a program written in BASIC.  We
could assign some line numbers to PostScript statements, so that 
we can easily refer to them.  Those line numbers would not become
part of the source code.  Such a user interface would be much
more useful for learning PostScript than the current interfaces
which scroll the statements off the top of the screen, and force
you to reenter all statements if you make a slightest mistake. 

Ivan N. Bach                      Tel (408) 986-9400, x508
QMS, Inc.                         Fax (408) 727-3725 
2650 San Tomas Expressway         arpa: ib@imagen.com 
Santa Clara, CA 95051             uucp: decwrl!imagen!ib