jvmiller@plato.rdrc.rpi.edu (Jim Miller) (06/09/89)
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 to a dot-matrix printer, hardcopy output quality is usually pretty poor. These same CAD packages will usually produce output for a HP pen plotter. By redirecting the HPGL output from these CAD packages to PLT: high quality hardcopies can be generated. PLT: inquires from preferences your desired resolution and takes advantage of the printer's capabilites by mapping the plotter's coordinate system onto the printer's coordinate system. It assumes that the printer is using 8.5" x 11" paper. Most of the HPGL primitives have been implemented. I have yet to find a CAD package that uses the commands I haven't implemented (the only command no implemented that would be useful is the rotate command [allows portrait plots]). 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. We have tested the handler on a Okidata-292 dot-matrix printer and it works great (sorry no color support as of yet). My problem arises when using a LaserJet printer. Apparently the dump_rast_port routine send a reset as its first packet. This reset causes the LaserJet to eject a page. This is very unsatisfactory when the raster section is only 50 lines tall. My question is: Is it possible to inhibit the dump_rast_port routine from sending the reset packet at the start of each dump (or from the dumps after the first one)? 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). This was our solution to the inadequate CAD hardcopy routines, plus it gaves us a HPGL interpretor. I hope someone has an answer to my question so I can move onto emulating more commands (like fills, arcs, etc.). Jim Miller Rich Champeaux
daveb@cbmvax.UUCP (Dave Berezowski) (06/09/89)
In article <5375@rpi.edu> jvmiller@plato.rdrc.rpi.edu (Jim Miller) writes: > >My problem arises when using a LaserJet printer. Apparently the dump_rast_port >routine send a reset as its first packet. This reset causes the LaserJet >to eject a page. This is very unsatisfactory when the raster section is only >50 lines tall. My question is: > > Is it possible to inhibit the dump_rast_port routine from > sending the reset packet at the start of each dump (or from the > dumps after the first one)? > > Are you sure you are testing with V1.3? The V1.3 HP_LaserJet driver should not be sending a reset to the printer for each graphic dump. Are you going to be at DevCon? We could go over any details of the printer.device that you're interested in. Kudos for your plotter.device (PLT:), I've always wanted to do one but there was never the resources here to do it as well as the printer.device. Regards, David Berezowski
tony@hp-sdd.hp.com (Tony Parkhurst) (06/10/89)
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
rachamp@mbunix.mitre.org (Richard A. Champeaux) (06/12/89)
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 )\
rachamp@mbunix.mitre.org (Richard A. Champeaux) (06/12/89)
I forgot to address some things in my response to Tony's post. On color support: What I'm currently doing when there are interseting lines of different colors is putting the darker color down. After the pen colors are read, I determine each one's brightness. Currently this is done merely by adding the R, G, and B fields together. The SetPixel() function compares the brightness of the color of the point in the raster to the color it's trying set. The color that is put there is the darker of the two colors. Although this will not accruately emulate the mixing of the colors on a page, it's as close as I can think of doing it. On a real plotter, a yellow and blue line might mix to give you green (depending on the type of pen and paper). On my implementation, the yellow dots would become blue dots where the lines intersected. On printer driver resets and formfeeds: I found two flags in the 1.3 RKM that solved this problem. They were SPECIAL_NOFORMFEED and SPECIAL_TRUSTME. The only thing I have do to do now is look to see how to send a formfeed at the of the plot. Rich Champeaux (rachamp@MBUNIX.MITRE.ORG)