jensen@gt-eedsp.UUCP (P. Allen Jensen) (05/18/88)
I need a program to do a screen-dump from an HP9000c320. The images are
being done in gray-scale. The hard-copy devices I have to choose from
are an Apple Laserwriter Plus, an HP Laserjet, and a QMS Laserprinter.
The software should be free and I need source.
Thanks
--
P. Allen Jensen
Georgia Tech, School of Electrical Engineering, Atlanta, GA 30332-0250
USENET: ...!{allegra,hplabs,ihnp4,ulysses}!gatech!gt-eedsp!jensen
INTERNET: jensen@gteedsp.gatech.edutonyj@stan.UUCP (6704) (05/20/88)
Why not write it yourself?
paul@hpldola.HP.COM (Paul Bame) (05/25/88)
> / hpldola:comp.graphics / jensen@gt-eedsp.UUCP (P. Allen Jensen) / 9:36 am May 18, 1988 / > I need a program to do a screen-dump from an HP9000c320. The images are > being done in gray-scale. graphics(7) in the HP-UX manuals details how to talk directly to the frame buffer - it's just a big array - and it's easy to do: fd = open(/dev/crt) ioctl(fd, GCMAP?, &ptr) This takes from 2 to 10 lines depending on how neat you are and how much error checking you do. Newer versions of Starbase also do such things as screen dumps but I don't have a reference, look up the 'pcltrans' program. > The hard-copy devices I have to choose from > are an Apple Laserwriter Plus, an HP Laserjet, and a QMS Laserprinter. The other half of your problem is how to represent the gray-scale image on a non-gray-scale printer. I believe Postscript allows you to push a gray-scale image at the printer without worrying about this problem - otherwise you'll have to dither or threshold your image before printing. > The software should be free and I need source. The pseudo-code and the graphics(7) reference should be enough to solve your first problem quickly. The second part isn't specified well enough to know what to say about it. --Paul Bame hplabs!hpldola!paul
keith@tut.cis.ohio-state.edu (Keith Boyer) (05/26/88)
In article <286@gt-eedsp.UUCP> jensen@gt-eedsp.UUCP (P. Allen Jensen) writes: >I need a program to do a screen-dump from an HP9000c320. The images are >being done in gray-scale. The hard-copy devices I have to choose from >are an Apple Laserwriter Plus, an HP Laserjet, and a QMS Laserprinter. >The software should be free and I need source. >Thanks >P. Allen Jensen If I understand your request correctly and if you're running HP-UX then the answer is simple. There is a sample program in /usr/lib/formatters/pcl, I beleive, that uses starbase library calls to do this. It works with the HP Laserjet as well as other printers such as Line Printers. The name of the program is bmprint. You have to play with the associated configuration file to get what you want, but its pretty straight forward. -- -- Keith M. Boyer, Department of Computer and Information Science ----- --- The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 ---- ---- keith@cis.ohio-state.edu or ...!cbosgd!osu-cis!keith --- ----- THIS SPACE INTENTIONALLY LEFT BLANK --
rmf@actnyc.UUCP (Robert M. Fuhrer) (05/26/88)
In article <11390009@hpldola.HP.COM> paul@hpldola.HP.COM (Paul Bame) writes: >> I need a program to do a screen-dump from an HP9000c320. The images are >> being done in gray-scale. > >graphics(7) in the HP-UX manuals details how to talk directly to the >frame buffer - it's just a big array - and it's easy to do: > > fd = open(/dev/crt) > ioctl(fd, GCMAP?, &ptr) > Well, when I was using an HP Series 9000 Model 320 with HP-UX (awhile ago), I recall finding a system call which maps the frame buffer directly into the process's address space, so that normal memory references can be made to the locations representing the pixels. Of course, anybody can do this, so it's not generally speaking a good way of *writing* to the screen (since two processes can interfere with one another), but for reading (e.g., screen dumping), it's fine. >> The hard-copy devices I have to choose from >> are an Apple Laserwriter Plus, an HP Laserjet, and a QMS Laserprinter. Once you've got that, it's very simple to dump bitmaps to a LaserJet (or LaserJet Plus or II); the following escape sequences exist: 1) Prepare LJ to receive bitmap data at a given resolution (75, 150, or 300 dpi), 2) Transfer a raster scan line (telling the LJ how long it is) 3) End raster transfer mode I've done both of these procedures (although the LJ part was on an HP320 running their Pascal Development System), and they're both quite easy... As far as gray scale and/or dithering, I'm not big on that stuff, but it depends on what sort of image you've got to begin with. -- The Foundation for Unmitigated Sillyness uunet!actnyc!rmf Department of Redundancy Department City of Kansas City, Kansas
glen@hpfcmr.HP.COM (Glen Robinson) (05/27/88)
/ hpfcmr:comp.graphics / keith@tut.cis.ohio-state.edu (Keith Boyer) / 6:16 am May 26, 1988 / >In article <286@gt-eedsp.UUCP> jensen@gt-eedsp.UUCP (P. Allen Jensen) writes: >>I need a program to do a screen-dump from an HP9000c320. The images are >>being done in gray-scale. The hard-copy devices I have to choose from >>are an Apple Laserwriter Plus, an HP Laserjet, and a QMS Laserprinter. >>The software should be free and I need source. >>Thanks >>P. Allen Jensen >If I understand your request correctly and if you're running HP-UX then the >answer is simple. There is a sample program in /usr/lib/formatters/pcl, I >beleive, that uses starbase library calls to do this. It works with the HP >Laserjet as well as other printers such as Line Printers. The name of the >program is bmprint. You have to play with the associated configuration file >to get what you want, but its pretty straight forward. ---------- You can also use an HP-UX command pcltrans if you use a starbase library call to create a starbase format bitmap file. The starbase bitmap file takes about 5 - 15 seconds to create (it contains header, colormap, and frame buffer data). Then you can fork a child process that invokes pcltrans allowing your current program to continue while the work of doing the error diffusion et. al takes place in the (orphaned) child. Glen Robinson
paul@hpldola.HP.COM (Paul Bame) (06/01/88)
>>graphics(7) in the HP-UX manuals details how to talk directly to the >>frame buffer - it's just a big array - and it's easy to do: >> >> fd = open(/dev/crt) >> ioctl(fd, GCMAP?, &ptr) >> >Well, when I was using an HP Series 9000 Model 320 with HP-UX (awhile ago), >I recall finding a system call which maps the frame buffer directly into >the process's address space, so that normal memory references can be made >to the locations representing the pixels. Yep, the open/ioctl maps the frame buffer into user space just like you mention.