Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!pasteur!ucbvax!hplabs!hp-sdd!tony
From: tony@hp-sdd.hp.com (Tony Parkhurst)
Newsgroups: comp.sys.amiga
Subject: Re: PLT:, HPGL, DumpRastPort()
Keywords: PLT:, HPGL, DumpRastPort, CAD, handler
Message-ID: <2125@hp-sdd.hp.com>
Date: 9 Jun 89 17:31:25 GMT
References: <5375@rpi.edu>
Reply-To: tony@hp-sdd.UUCP (Tony Parkhurst)
Distribution: usa
Organization: Hewlett Packard, San Diego
Lines: 74

In article <5375@rpi.edu> jvmiller@plato.rdrc.rpi.edu (Jim Miller) writes:
>
>My co-author (Richard Champeaux) and I have been writing a file-handler
>that accepts HPGL (pen plotter) commands and dumps a rasterimage to a dot-
>matrix printer.  Since most CAD packages will only perform screen dumps
>[...]
>It assumes that the printer is using 8.5" x 11" paper.  Most of the 
>HPGL primitives have been implemented.                  ^^^^

I am really impressed.  Since there are about 200 HPGL commands.  Most software
solutions usually only do about 6 or so.  HPGL labeling is almost never
one of them (requires its own character generator and fonts).
[yes, I understand you said "primitives", not "commands"]

>I have yet to find a CAD package that
>uses the commands I haven't implemented.

This is not hard as about 99% of all CAD packages use only the basic subset
of about 9 HPGL commands.  There are very good reasons for this: the only
way of making sure that what is on the screen matches the output is not to
use any advanced HPGL feature like text; each HP plotter has some different
commands, and one would have to have a different driver for each; since
the CAD package has already implemented high level primatives (like text
or area fill) for the screen and to drive less intelligent plotters, it costs
little to use this same functionality to drive all the plotters (and saves in
support costs).

>(the only command no implemented that
>would be useful is  the rotate command [allows portrait plots]).

Yes this would be useful.  It would be a pain to do after rasterizing, but
rotating vectors should be straightforward.

>PLT: divides the printer's page into smaller rasters that it plots separately
>then dumps to the printer.  This prevents the handler from grabbing all of 
>the computer's memory.  We then use the printer driver's dump_rast_port
>command (I don't recall the exact name) to dump each raster to the printer.

Does this mean you buffer the whole plot in vector form and rasterize each
swath?  Seems like the best approach for your contraints.

>We have tested the handler on a Okidata-292 dot-matrix printer and
>it works great (sorry no color support as of yet).

You mean you haven't implemented "SP" yet?  Those of us with color printers
would certainly wish for that.  Your problem here will be deciding what
to do at intersections of crossing vectors of different colors.


>Also, if anyone is interested in testing this handler then let me know how
>to get it to you.  I would like to see (hear?) how it performs on other
>printers (I only have access to the Okidata-292 and LaserJet Series II).

I volunteer for testing with the PaintJet.

>This was our solution to the inadequate CAD hardcopy routines, plus it
>gaves us a HPGL interpretor.


My question here is... how do you know when you have reached the end of the
data?  Do you get the equivilent of an EOF in the PLT: driver?  Many HPGL
applications do NOT send "NR", "PG", "AF" or "AH" which some VRC's use to
determine when it is time to print.  They assume that the user will know
when the plot is done.

What kind of performance are you seeing with this?

-- Tony

-- 

Tony Parkhurst	( tony@hp-sdd.HP.COM )

"Is this Hell?  Or is this Texas?" "Both" -- Heinlein, _J_O_B: _A _C_o_m_e_d_y _o_f _J_u_s_t_i_c_e