From: jon@stat.tamu.edu (Jon Davis)
Subject: Re: Writing a postscript interpreter
Organization: Texas A&M University, College Station
Date: Thu, 15 Oct 1992 00:50:58 GMT

bobt@bbs1984.chi.il.us (Bob Tomasevich) writes:

>How difficult is it to write a Postscript interpreter?  I've seen the Adobe
>Postscript reference manual and Postscript seems to need a lot of math and
>parsing.  
> 

I work for a software company which has a high end PostScript compatible
interpreter on the market.  As far as how hard it was to write goes, it
is not TOO bad to get one up and running.  BUt getting it right, and fast,
is a royal pain in the rear.  The interpreter itself is pretty simple;
the problem is the vast quantities of support routines needed to be fully
Adobe compliant.  It all pretty much depends on how fast you want to be,
the upper bound of resolutions you want to support, and to what degree
you wish to comply with the Adobe specs.

PostScript's syntax is really simple, so it doesn't take much parsing at
all.  In fact, "parsing" PostScript means about as much as "parsing" Forth,
with a couple of trivial lexical quirks thrown in.

It's also not very math intensive until you get into halftone screens and
grayscale reproduction.  The problem is that it's very hard to get GOOD
halftones out of software fast enough to drive any of the devices on the
market.  (Note that getting halftones out of software is trivial; getting
irrational angled halftones good enough for the color dweebs in the industry
is a real headache.)

>I would be using C to write it.  I figure it can't be too difficult.  Am I
>right or wrong?

It's not a project I'd want to take on in my spare time; of course, I'd
probably be obsessed with getting it exactly right, being the masochist
that I am :-)  We use a language developed in house to implement our
interpreter.  (Incedentally, I'm going to release the Amiga
port of the language as soon as I can find a week or so of spare time
to write documentation.  It's Forth based, but takes a very non-forth
approach to module creation/browsing.)   C is a very common choice for
an implementation language, though.

>And while I'm on the topic, which books are a decent reference?  The Adobe book
>is pretty good but not that great.

Well, the Adobe Redbook is the bottom line reference; a better book to
learn about programming in PostScript is "Inside PostScript," though
I forget the author and publisher.  "Inside" goes into far more detail
about possible implementations of some of the primitives than the Redbook
does.

>Bob Tomasevich, Sears Point of Sale programming team.
>My opinions are not those of my employer, Sears, Roebuck, & Co.
> 
>Please, someone buy something from us... we're not that bad!

Please note that I'm by no means a PostScript guru or anything; my work with
the company deals largely with the post processing end of the business, IE
driving specific devices and getting out good halftones.  (argh...)  If you
have any more specific questions about the language, I'd be glad to help
you find the answers if I don't know them off the top of my head.

Hope this was helpful in some way :-)


------------------------------------------------------------------------------  
--Jon Davis                           Software Engineer (Read as: Slave) 
  jon@stat.tamu.edu                   Software Construction Company, Inc
      -- Disclaimers are for wimps. --