marcel@dx7.UUCP (Marcel Bernards) (10/20/88)
Hello News Readers, I'm posting this article again, because our modem didn't work previously... I'm looking for a conversion script/C-language source in order to translate some HPGL penplotter files to an Apple LaserWriter If anyone knowns about this one , please E-mail, =============== Local UNIX & Network System administrator =================== Marcel Bernards | e-mail: ..!mcvax!ecn!marcel Netherlands Energy Research Foundation, ECN | Telex : 57211 REACP NL P.O. Box 1 | Fax : -31 2246 4480 1755 ZG Petten (NH), Holland. | Phone : -31 2246 4342 --------------------------------------------+--------------------------------
mfox@hpbsla.HP.COM (Martin_Fox) (10/27/88)
I would be interested in seeing this one. Not because I ever need to do such conversions; I'd just like to see how it was done. 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. 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. 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. 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. Martin Fox Hewlett-Packard Boise Division
dave@sun.soe.clarkson.edu (Dave Goldblatt) (10/31/88)
From article <500001@hpbsla.HP.COM>, by mfox@hpbsla.HP.COM (Martin_Fox): > > I would be interested in seeing this one. Not because I ever need to do > such conversions; I'd just like to see how it was done. > I have received a number of requests for such a program, and a while back I received one written by D. McCormick. It is now available from the sun.soe.clarkson.edu archive server. To receive the files you must send mail to archive-server@sun.soe.clarkson.edu containing the line: send hpgl hpgl.shar.1 and send hpgl hpgl.shar.2 These must be in two different mail files, since some mailers will truncate files > 100K. If you are on a UUCP or BITNET site you must use the path command to avoid bounced responses from the server; send mail consisting of the word "help" for detailed instructions on the server. You can also ftp it from sun.soe.clarkson.edu in ~ftp/pub/hpgl/*. -dg-
gandalf@csli.STANFORD.EDU (Juergen Wagner) (10/31/88)
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
mfox@hpbsla.HP.COM (Martin_Fox) (11/04/88)
Once again I was writing notes while eating lunch and stuck more than my
sandwich in my mouth.
I guess the word I focused on in the original note was "script". I have
noticed more than one request for HPGL <-> PostScript converters; some
of them make it sound like a fairly simple chore, either way. My note
was a rather murky response to this.
In the case of HPGL -> PostScript, I did not mean to imply that a
PostScript program resident in the printer would need to interpret
HPGL. Somewhere along the line, however, the HPGL source would need
to be parsed; somewhere else along the line the modal information would
need to be handled. In the case of PostScript -> HPGL, however, the
PostScript code would need to be interpreted to handle procedures, etc.
Neither case is trivial.
As for converting from any given 2-D graphical description system to
PostScript; remember that some systems use an OR-ing model for placing
new images on the page (1 bits are written black, 0 bits are transparent).
This can produce some effects that are difficult to achieve in PostScript,
such as lines drawn with cross-hatches where only the hatch is drawn,
allowing the underlying image to show through between the hatch marks.
Between this and *fonts*, it can be more difficult than you think to
map a given PDL to PostScript (particularly if you want the image
produced in less than an hour).
Martin Fox
HP Boise Division
My Own Private Idaho