Author: Evan Langlois (neptune.sabre.com)
Date: 07-26-2000 08:28
Hey Flash,
one solution that may or may not be available to you ... dunno really. But, see if you can find a port of gnu ghostscript to the ST (should be one around, or you can probably port it without a ton of trouble if you have a C compiler, especially if you have MiNT and long filenames).
Then, all you have to do is use a regular postscript driver to print to a file. Send the postscript file through ghostscript, and ghostscript will convert postscript data to a number of filetypes (including pbm, gif, jpg, png, various X formats, and a wide range of printer data format). Take the output of ghostscript and send it to your printer port, and you should get the output you desire, in color.
If your Atari supports named pipes or named sockets, and you have some programming ability, you can (at least with the way MiNT handles devices), rename /dev/prn (I think thats the mint name of the printer device isn't it?) to something like /dev/realprinter. Make a socket or named pipe as /dev/prn. Read from /dev/prn, it will block. When you get data on /dev/prn, open a new pipe to gnu ghostscript with ghostscript's stdout redirected to /dev/realprinter (or the raw device /dev/centr isn't it? or something like that) and just close the ghostscript pipe when you get the end of your postscript data (I think you can detect start and end of pages by looking at the postscript headers). Then your regular postscript driver will write to the pipe /dev/prn (assuming it uses GEMDOS to talk to the printer and not direct hardware writes) and everything will automatically work for you. Oh yeah, I guess that would be U:devprn Its been a long time.
I did something real similar back when I had my 16Mhz Ste in order to make a print spooler that would rename /dev/prn to a temp name as soon as it got data coming in, fork itself, and make a new /dev/prn pipe for the next pipe so it could handle multiple requests (there was a race condition, but how often do you have multiple apps printing at EXACTLY the same time?). It would spool it all to the hard drive and then slowly piece it out to the printer using non-blocking IO calls so it wouldn't lock the machine waiting on the slow centronics port. I don't have the code anymore, sorry.
I eventually wanted more RAM for this type of stuff, a faster CPU, and better parallel port support that wouldn't lock the machine if the port was busy, and I use Linux exclusively now on a custom-built PC (cheap and fast if you know the ins and outs of the PC hardware market and avoid the bad stuff).
|
