Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!csli!gandalf
From: gandalf@csli.STANFORD.EDU (Juergen Wagner)
Newsgroups: comp.lang.postscript
Subject: Re: HPGL -> PostScript Converter wanted !
Message-ID: <6179@csli.STANFORD.EDU>
Date: 30 Oct 88 20:56:45 GMT
Article-I.D.: csli.6179
References: <133@dx7.UUCP> <500001@hpbsla.HP.COM>
Reply-To: gandalf@csli.stanford.edu (Juergen Wagner)
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 64

In article <500001@hpbsla.HP.COM> Martin_Fox (mfox@hpbsla.HP.COM) writes:
...
>   Postscript to/from HPGL comes up every now and then on the net.  The
>   problem is that either language would have to be INTERPRETED to handle
>   the conversion.

I don't see why *EITHER* way an interpreter is necessary. It is clear that
PostScript is much more powerful than HPGL but it is no problem to compile
HPGL into a more powerful formalism.

>		    HPGL is a very mode dependent language; to correctly
>   handle a given command you must track information from previous commands.
>   As a simple example, PD 1, 1 will produce different results depending on
>   1) whether your are in relative/absolute mode, 2) polygon/non-polygon mode,
>   3) symbol/non-symbol mode, 4) pen up/pen down, etc. etc.  Then there is
>   scaling to handle, not to mention the polygon buffer, which behaves
>   differently than a Postscript path for stroking and filling.

As for scaling, moving/rotating the coordinate system, that no big deal in
PostScript. It's just one command. And if you want to make the effect local,
put the code into a "gsave...grestore" block. Of course, any graphics language
of a non-trivial complexity (i.e. where commands typically don't specify all
their input parameters in the command invocation but take some from some kind
of environment) have these problems. PostScript, however, allows you to deal
with that. The problem here is more a compiler technique question.

>   I won't even consider Postscript -> HPGL; Postscript has procedures,
>   variables, and all the other goodies that make it a general purpose
>   language, which HPGL is definitely not.

Might be tricky. Yet, there is Crispin Goswell's (I hope I remember the name
right) PostScript interpreter which basically translates to pure raster
images.

>   By the way, I am not saying HPGL -> Postscript cannot be done, I am only
>   saying it is definitely not a script, not if you want to handle the
>   majority of HPGL correctly.

I believe, there is a basic misunderstanding here. The idea of having a
converter of some kind doesn't mean that if you have to have something written
in language A emulating language B. With PostScript that's the case because
PostScript is a universal programming language. HPGL isn't!

That's why people need converters. A converter compiles a given description
from one language to another language. Sometimes that's easy (e.g. HPGL to
PostScript) and just a matter of writing tedious pieces of code (each
emulating one function of the source language), and sometimes that's difficult
(e.g. PostScript to HPGL) because the target language is far less powerful
than the source language, and YOU have to write the high-level functionality
provided by the source language.

To summarize: I don't think, it is very difficult to implement a translator
from any existing 2D graphics language to PostScript. You have to make a
tradeoff between compile-time and run-time. You can convert your favourite
graphics language code into PostScript either on a Cray (where the Cray is
supposed to do certain things faster :-) than your PostScript interpreter,
so you can afford to send a pure raster image to the printer), or on a cheap
home computer with 64 kB memory (where your printer has more computation
power and more memory than your computer :-), so you'd better let PostScript
emulate the printer language).

-- 
Juergen "Gandalf" Wagner,		   gandalf@csli.stanford.edu
Center for the Study of Language and Information (CSLI), Stanford CA