Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!pyramid!prls!philabs!linus!mbunix!rachamp
From: rachamp@mbunix.mitre.org (Richard A. Champeaux)
Newsgroups: comp.sys.amiga
Subject: Re: PLT:, HPGL, DumpRastPort()
Summary: It now supports color.
Keywords: PLT:, HPGL, DumpRastPort, CAD, handler
Message-ID: <55947@linus.UUCP>
Date: 12 Jun 89 14:48:09 GMT
References: <5375@rpi.edu> <2125@hp-sdd.hp.com>
Sender: news@linus.UUCP
Reply-To: rachamp@mbunix (Champeaux)
Distribution: usa
Organization: The MITRE Corporation, Bedford, Mass.
Lines: 102

In article <2125@hp-sdd.hp.com> tony@hp-sdd.UUCP (Tony Parkhurst) writes:
>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"]

   What Jim meant, is that he took a manual for a HP plotter (don't know which
one) and implemented most of the "basic" commands that it listed.  The commands
that weren't implemented were the ones it said were contained in an Extended
Graphics Cartridge (or something like that).  These were commands like arcs,
fills, and other such commands.  It does implement the scaling commands, text
commands, tick commands, and most of the other commands that would be usefull
if you accessed it through your own software.  The font is not changeable and is
not identical to the plotter's font.
 

>>(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.

   That's how it will be implemented, we just haven't gotten around to it yet.
Not terribly necessary though if you're using a CAD program, since they tend
to the translation themselves.

>
>>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

   That's exactly what we're doing.  The lines are inserted into a sorted 
linked list until the file is closed.  Then the page is rasterized from this
list.  A sorted list is used so that the entire list need not be searched
to find the lines for a particular raster.  When a line has been completely
rendered, it is deleted.  Actually the data structure is a combination of
a binary tree and a linked list.  The binary tree was added to increased 
insertion speed, since with very large plots (3000 lines or more), a straight
linked list approach really slows down.

>
>>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.
>

    Yes, we did implement SP.  At the time of that posting, however, the
pen number was was used as the line thickness.  Yesterday, I implemented
color support.  At the moment the pen colors and thicknesses are hard coded
into the handler.  Tonight, I plan to change that.  I saw a field in the
mount list discription, that said you could define a string that will get
passed to the handler at startup.  If I can get it to work, I'm going to use
that field to set the default colors and thicknesses.  The string will be
in the form:

RGB-t/RGB-t/RGB-t/.....

Where RGB is the pen color (eg f00,ff0,05f) and t is the pixel thickness.
To change the colors on the fly, you simply append the pen information to the
device name (eg "plt:RGB-t/RGB-t/RGB-t").  The handler decides how many
bit planes to use from the number of pens colors specified.  This way,
memory and time is not wasted manipulating bit planes that arn't needed.  
Right now I planning to set the limit at 15 pens (pen 0 is always white),
this is the most pens that IntroCad uses.  If someone gives me a reason
to allow more, it's easily changed.


>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.
>

   Right now it waits until the file is closed before dumping.  This is 
because we didn't know the command names for ejecting the paper.  If
NR,PG,AF, and AH perform those functions, we'll put them in.  The way
the code's setup, it'll only take about 5 minutes.

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


Rich Champeaux ( rachamp@MBUNIX.MITRE.ORG )\