Anyone here allready know anything about writing printer drivers...

or at least, writing a program that can break an image into a grid and put a color value in each space of the grid, and then process that info into a long file of coordinates and color pixels?

#!/usr/bin/perl

use GD;

my $image = GD::Image->new("whatever.jpg");

my ($width, $height) = $image->getBounds();
foreach $x (0..$width) {
foreach $y (0..$height) {
my($red, $green, $blue) = $image->rgb($image->getPixel($x, $y));

print "color is $red $green $blue at $x $y\n";
}
}


Hey, that's the easy part.

Chagrin - please elaborate on this - did you look at the "4 color painthead" in the cnc gantry printer thread?

so this code - can you repost it with comments?

i am looking at it. it.. opens a file, finds the files resolution, devides by that number and then finds the color value for each division. the it prints the data to the screen? tell me more! MORE. i was jsut this minute reading about ghostscript and thinking about a postscript vector based driver...

here is somethign that may help with this problem.


"Printer Driver Block Diagram"

http://techpubs.sgi.com/library/dynaweb_docs/0530/SGI_Developer/books/Impr_PG/sgi_html/figures/fig3-1.bw

Aw geez, "four color painthead"... now you want me to convert it to CMYK. I'm trying to answer one question at a time :)

OK, back from the beginning, yes you did get the basic flow of the program right -- it's moving pixel by pixel in the image and printing the RGB values of that pixel. I don't see any need to copy all that data into a "grid" as you mentioned earlier since that can all be done on the fly as the hardware moves. I was just trying to demonstrate how you can walk through an image and look at those pixel values.

I saw in another thread that someone recommended ghostscript, and this really isn't the way to go. Ghostscript is mainly used when the hardware speaks the standard language of Postscript, which nearly all printers do, but that's completely out of scope for us. Similarly, using vector-based printing (like a plotter) as opposed to raster-based printing (like every other printer) would add massive levels of complexity to the problem. I can't even begin to ponder all of the algorithms used to find the path for the printhead and routines necessary to draw something as simple as an arc, much less optimizing either. "floodfills" are completely out of the question. Leave that stuff to the professionals :D

i use a program for doing signmaking.
In the program there is a proffesional RIP.
For all large format printers there is a driver in the program.
Maeby that will be usefull.
I will post the question on a german cnc forum.
Maybe i can find there somebody who can write a printerdriver.

chagrin - thanks for the reply!

it seems i have 2 choices - either trying to try and use a mix of regular plotter CNC software with 4-color seperations run into a "raster to vector" convertor

or to write my own raster based software. this is preferable because it will be fun. if the program starts in the uper left corner of the image and reads to the right, it can scan the image as the painthead reproduces the dots..

how would i just use a .bmp? is there a good source of info on this type of coding?

- what is that provess called in the code you wrote, where can i learn more about it? is there a way to use it with CMYK values instead of RGB?

i can iamgine easily getting the thing to move (x)steps to the left for each pixel, and (x) step forward to advance to he next line, then seeing what color is in that cell, and sending the command to a program in a PICmicro that mixes the paint and produces the dot, send a "go forward" command and then it does it again.


thanks....

publitime- i am trying to find a forum where people are working on these issues. i know there are at least 2 places to look but havent found any. I am looking for:

1-people who are involved in image editing software that would understand how to process a file into coordinates and color values.

2-people who are involved in writing general hardware or printer drivers...

HPGl, HP RTL are both acronyms that seem usefull to look at.


does the information at:
http://www.ghostscript.com/doc/gnu/...es.htm#Uniprint

help or confuse things?
anyone?

vacpress

I'm also searching the net to find a way to write a driver.
What will be the best program for you to write a driver

vac

Take a look at
http://www.noobeed.com/
There can be something intressting

You don't really want to get into the business of decoding image file formats directly. Even bitmaps have numerous headers and compression stuff you'd need to wade through before you could even begin to make heads and tails of the pixels in the image. The "GD" library is an excellent place to start to avoid all that stuff, as I did in my example.

I barely know anything about printing processes, but I do know it's possible to convert RGB to CMYK. It's something on the order of:

$C = 1 - ( $red / 255 );
$M = 1 - ( $green / 255 );
$Y = 1 - ( $blue / 255 );

my $K = 1;

$K = $C if ($C < $K);
$K = $M if ($M < $K);
$K = $Y if ($Y < $K);

$C = ($C - $K) / (1 - $K);
$M = ($M - $K) / (1 - $K);
$Y = ($Y - $K) / (1 - $K);

...but I think I have my intensities inverted. Inevitably there will be a lot of tweaking to get the colors looking right.

what is a "GD" liubrary? a perl "graphics decode" lib?

as for rgb to cmyk conversion, that looks like what i was picturing.. so the rip program will create me a "raw" image format of just pixels? or is that what the GD lib takes out of, say, a jpeg?

All the ghostscript stuff seems hard but it's not really too difficult. In a practical application you would first create your postscript file by installing a generic postcipt printer and windows and setting it to print to a file instead of a printer port, now you can print from any any application and generate a postscript file.

Then on the command line something like:
ghostscript @ras32.upp -sOUTPUTFILE=test -sPAPERSIZE=a10 cmyk.ps -c quit
and we have rasterized the input file cmyk.ps and have a binary output file test in sun raster format.
The format is very simple and consists of a 32 byte header most of which we can thow away, but we will want to grab the X and Y pixel numbers so we can do a "carridge return" at the right time.
The rest of the file is just a string of bytes looking like 0000YMCK in binary where for example C will be 1 if the cyan jet should be on for that pixel or 0 if it is off.

aah perfect. i have got a few links bookmarked now for the GDlib and the ghostscript stuff.i know i read about a ghostscript to HPGL print driver before... in some wierd pdf file... i have it on another windows isntall.. gotta go looking.

thanks for the help so far.. you are the only respondant...

i posted a thread full of photos of the start of the prototype build. it will hopefully be done in a week or so..

vac
"ghostscript to HPGL print driver" I'm not sure what you mean by this,
here's a little background for you
PCL, HPGL and Postscript are all printer control languages and there are many others also.
Postscript is the most powerfull of the lot and in fact is a self contained programing enviroment, on 30 percent of it's operators have any thing to do with putting marks on paper.
Postscript is closely related to the pdf format and it's strength is that one file will print the same on any Postscipt printer. Postscript printers used to be a very expensive option due to the processing power required in the printer to process the PS file and turn it into a rater file to be printed. CPU etc are getting cheaper but you still won't find PS as a option on cheap printers.
Ghostscripts main purpose in life is to allow "dumb" printers to print PS. So it's pretty much a perfect match for you application, you just need to tell it about you output device and it produces the bit map. At a basic level all you need to tell it is the resolution of your output device (dpi). It can do all sorts of tricky things needed to get really nice output like compensating for your round blobs of paint spilling out of their square pixels or your yellow being not quite yellow.

Looking at your plans your device just rolls along the top of the surface it's printing on to and isn't firmly attached? Depending on how fast you want to move the head you might want to think about having a counter weight which moves in the oppersite direction to the print head to stop the whole assembly skating sideways when the head stops and starts. You can work it out easily enough F=ma.

yes - i have been increasingly concerned about skew from the head starting and stoping. that must be why the pixation machine looks like it must weigh a ton. i am going to probably work on making the print head as light as possible, to avoid that issue, and put all the supporting equipment in the sides. hopefully the thing will be assembled in a week, so i can do some gcode driven 'normal' cnc stuff with it and a sharpie.

thanks for the postscript and ghostscript info. i knew ghostscript wa an open source postscript, and i know about postscript from work.. i use vextor gaphics all the time... im fairly familiar with the differences.. i just had no idea a few days ago how difficult, or easy as it turns out, it would be to process the image. turns out its gonna be kinda straight forward when i get to that point. i hope you will still be around to help.

what is your connection to this forum? are you a "cnc" guy?

I've been lurking around here intermitantly for a while, I'm building a small mill in between all the other half finished projects ... Haven't started on the construction proper but i have built a 3 axis servo controller based around a AVR Micro and got it working well at a 40Khz step rate. I'm stalled for want of cash right at the moment but I've got a big pile of bits and the design mapped out in my head.

Sorry if I was givving a lesson that you didn't need but if you were to just look at the ghostscript page it's not a all obvious what it's all about. It is possible to download a postscript file to a PS Interpreter which will then enable it to rip HPGL files, maybe thats what your weird pdf is about?

no. this was a article on how to build your own HPGL plotter. i will find it and post it to the technical articles section. it specifically delt with loading a vector format file into this thing and moving steppers.. cant remember where i found it. it was durring a first round of research on cnc a years ago...

as for the graphics lib stuff. i have learned alot from you and my friend mike who dosent really have time to help, or understanding of stepper motors.. he told me almost the exact same thing you did about using a graphics lib to get the pixels and colors..

and you are right, the ghostscript page is confusing.. i got a few things out of a cursory scan of it:
1-ghostscript can convert vector to raster.
2-ghostscript can be used as a print driver
3-ghostscript is opensource

4-there was no mention of writing printer drivers that dont use PCL or something.. and thats my new question : can i write a driver that works all nice and "file -> print" and the it loads the driver? so it acts integrated within windows?

i dont need this feature at all, it would just be super eleeete.

and as for your servo controller - i got the impression its very difficult to design your own servo controller.. something about complex math? did you start with control algoithms from somewhere?

if you are at all interested in building one of these also, i will send you the solidworks file, and you can view it with "edrawings" if you dont have SW. that way you can print templates.

i almost built it out of nice baltic birch plywood to save $$, so im sure you could do so if you cant get acrylic.

the appealing thing about this project to me is it can be built with mostly broken printer stuff.

maybe the best way is to use a HP 74...... driver.
i have find out that adobe streamline can also raster a photo.

You can set up ghostscript so the whole process is intergrated and you just click print and it makes the bit map and sends it to the printer port. I gave the command line example to make it clear what was happening. You could write your own printer driver for GS if you really wanted to spend the time but a simple raster format output is probably all you need and is dead simple to process with a PIC or similar. Another way would be to run the output file though a script to convert in to gcode and use spindle & coolent controls to turn you jets on and off.

Tthe standard PID algorythm is very simple and only takes a few lines of code. 90% of the code in my controller deals with the lcd and keypad used to enter the pid coefficents and display the current position, jog without a computer etc.

tachus42,
If you can help, I got ghostscript - working fine to screen & my printers - but I can't get it to output to file? I've been through the online & local help files and it just doesn't seem to do what I tell it. Could you send me a literal example of sending a .eps file to a binary file on my harddrive? then I could look at the file?

This is pretty much how my BMP2Gcode compiler works, I atleast know how to sort through the data in a BMP but I could not figure out the other formats, so this would be great.
thanks

You might consider "ImageMagick" instead of Ghostscript. ImageMagick is essentially an image manipulation tool, but it is capable of converting/manipulating .eps, .pdf, .ps, .ps2, .ps3, etc. files in addition to any other graphics format you've ever heard of. Let us know what operating system you're using so we can help you better.

Going back to the original topic, though, postscript is just about the hardest method you could possibly use to talk to a CNC painter. It would add massive levels of complexity to both the electronics of the CNC painter and the software.

Im working in Windows98, because that is what I know-
And the problem I have is just that sending postscript data is unknown to me. But if I can just use GS as a 'print driver' to output a raster binary file that I can understand, then I don't care what format the image is coming from. As it is right now, I have to manually load my images into a Paintshop program & re-save them as a BMP. Then I can run them through my program. I'd just like to eliminate a step.

Im working in win XP, but i may try and make the main software DOS based so i can use these www.halted.com 100mhz dx4 tablets as the computer on my machines. if not dos, win95 and an external pulse generator.

I am going to develop a website where interestedc parties can contribute to this project. has anyone got any server space? or should i just ask for a file area here? im sure cncadmin would be into it...

As for the software and stuff, i would really encourage everyone here who is interested to begin building a machine. if you need some steppers, REAL BAD, I will send you some. ive got many smallish unipolars, but they are fine for a prototype of this, as there is no real contact between the work surface and the equipment. like an inkjet, it can be built to just barely work well enough...

checkout www.luberth.com - he has an amazing array of pertinent info available. i like his Cstep program as a DOS GCode interpreter, as it has opensource, and a nice GUI, and will run well on a 486dx4 100.

For software. I am still evaluating options, but my first experiments will be:

1- design simple line drawing in a vector format - such as PS, HPGL, DXF, AI
2- load the postscript into Cstep - print a 1-color image.

Thats gonna be thefirst run

For the second round of experimentation:

1-Using photoshop convert a bitmap image into its 4 color components and save them as seperate files
2-Using BMP22Gcode, or any simiilar technology, i will make 4 seperate g code files.
3-Manually program the robot to return to start position after each Gcode file.
4-Run the file sequentially, changing the color ink\paint in the gun. this will result in a fairly horrible image

From here its a bit hazy, it seems like some sort of "GL" library is going to provide the answers though. I want the machine to simply go line by line like a normal inkjet, and i want it to have a painthead that can deliver a very small dot, not a spraygun. this will probably be the longterm goal. short term might be holding 4 airbrushes and printing very large color plots using HPGL language. im still not totally versed on how to handle color changes -hopefull HPGL can ahndle more than 1 color pen - i think it can. this eliminates the need to dd "return to home" commands in the gcode.

one reason i liek phgl at this point is that there is ALOT of homebrew work that has been done with it.

sugestions?

Heres a link to a motion controller in a PIC. http://www.luberth.com/cstep/PStep.html

tachus42,
That, combined with your servo driver could result in a sweet little $15 package. :)

i would be very interested to hear more about the servo driver you created. the capacities, etc.

also worth noting, chagrin has written a preliminary perl program that will decode an image and prepare it for printing in 4 colors. we need to research dithering and other aspects of generating an image with pixels though, i think. i am also begining to devlop a virtual device to emulate the hardware so the software guys can see their results without the hardware.. this should be fun.. more to come, including a link to a webpage with the solidworks files, and a way for non SW users to view the thing in 3D, make measurements, see inside assemblies.

comments?

Vac i can send you some sample files if you like just let me know where to send them.

I don't have ghostscipt installed on a windows computer only on linux but this should still work.

Start the add printer wizard
Select Local Printer
For Port Select FILE:
For Model try Tektronix Phaser 600 - a color PS Printer with Very Large Paper sizes.
There should be generic postscript as well but I just checked and couldn't find it.
Now when you print to this printer it will create a PS File.
Find the ras32.upp file and edit it inserting a resolution command - see the confusing link i posted earlier, set it to some thing resonable like 10 dpi.
Try some thing like this
ghostscript @ras32.upp -sOUTPUTFILE=OutputFileName -sPAPERSIZE=a10 PostscriptFileName -c quit
I have used a tiny paper size here to keep the out file small. Open it with a hex editor and take a look.
Here's the format of the header: http://gmt.soest.hawaii.edu/doc/html/GMT_Docs/node118.html

I'm half way through writing a script to convert this raster file to gcode - a trivial task but I'm still learning perl but I'll post it here in a day or two.

If you want to build a dedicated controller for you machine the tablet looks very attractive but wahat about Input and output ports? To add these might be just as complicated as building a controller based around a microcontroller and realtime stuff is alot easier to deal with without the overhead of a OS. I'm not a PIC fan and Prefer AVR's not only for the more powerful clean archtecture but also the free gcc complier. But a PIC should do just as well if that's what your famililar with.
If you want to print left to right and then right to left you will need anough memory to hold one scan line so it can be reversed this probably means you need a microcontroller with a small ram attached - not too hard. I'm not sure if any of the PICs support this in hardware, but you can allways just attach it to a standard port and drive it with software.
The other way would be to reorder the output on the computer with a small prog before sending it to the printer.
What output resolution are you aiming at? If you get to ambitious you might be waiting hours or weeks for a print.
Have you looked at model or hobby sites for airbrushes? They seem to make some very small ones but they are very expensive. Perhaps you could make your own, a venturie and a valve, you might be able to use the electrical valves used for garden watering systems with a bit of modification. They are quite cheap and have 12 volt coils I think.

vacpress


where to find the information about the pattents on the wirejet from pixation.
Does somebody know if it is possible to find pictures of the parts who are pattented.

OK here is the Raster to GCode Converter pretty rough and barely tested but seems to work. I haven't put in the actual gcode yet but thats just a matter of editing the top part of the file.

#! /usr/bin/perl
{
# Put the GCode Snippets in Here

my $SetUpCommand="Set Up\n";
my $MoveXRightCommand="Move Right\n";
my $MoveXLeftCommand="Move Left\n";
my $MoveYCommand="Move Down\n";
my $CyanOnCommand="Cyan On\n";
my $CyanOffCommand="Cyan Off\n";
my $MagentaOnCommand="Magenta On\n";
my $MagentaOffCommand="Magenta Off\n";
my $YellowOnCommand="Yellow On\n";
my $YellowOffCommand="Yellow Off\n";
my $BlackOnCommand="Black On\n";
my $BlackOffCommand="Black Off\n";

my $buffer;

my $XPixels;
my $YPixels;
my @ScanLine;
my $XPosition;
my $YPosition;
my $ImageLength;
my $ImageDepth;
my $RasType;
my $MapType;
my $MapLength;

my ($InputFile, $OutputFile) = @ARGV;

open(INF,"<$InputFile") or die "\nCan't open input for reading: $!\n";
open(OUTF,">$OutputFile") or die "\nCan't open output file for writing: $!\n";
binmode INF;

read(INF, $buffer, 4); # read first 4 bytes and check for majic number 0x59a66a95 = 1504078485

if (1504078485!=unpack(N,$buffer)){die "Input does not look like Sun Raster\n";}
read(INF, $buffer, 4); # get width
$XPixels=unpack(N,$buffer);
read(INF, $buffer, 4); # get height
$YPixels=unpack(N,$buffer);
read(INF, $buffer, 4); # get depth
$ImageDepth=unpack(N,$buffer);
read(INF, $buffer, 4); # get Length
$ImageLength=unpack(N,$buffer);
read(INF, $buffer, 4); # get RasType
$RasType=unpack(N,$buffer);
read(INF, $buffer, 4); # get MapType
$MapType=unpack(N,$buffer);
read(INF, $buffer, 4); # get MapLength
$MapLength=unpack(N,$buffer);
read(INF, $buffer, $MapLength); #throw away Map

print "Image is $XPixels wide and $YPixels tall\n";
print "$ImageLength Bytes Long, $ImageDepth bits \n";
print "Rastype: $RasType, MapType: $MapType, MapLength: $MapLength \n";


print(OUTF $SetUpCommand);

while($YPosition<$YPixels)
{
print "Processing Line $YPosition \r";
read(INF,$buffer,$XPixels); #get one line
@ScanLine=unpack("c$XPixels",$buffer);
if($YPosition%2){reverse @ScanLine}; # if Y is odd reverse to print right to left
if($YPosition%2){print(OUTF $MoveXLeftCommand);}else{print(OUTF $MoveXRightCommand)};
for(@ScanLine)
{
if($_ & 1){print(OUTF $BlackOnCommand);}else{print(OUTF $BlackOffCommand);}
if($_ & 2){print(OUTF $CyanOnCommand);}else{print(OUTF $CyanOffCommand);}
if($_ & 4){print(OUTF $MagentaOnCommand);}else{print(OUTF $MagentaOffCommand);}
if($_ & 8){print(OUTF $YellowOnCommand);}else{print(OUTF $YellowOffCommand);}
if($YPosition%2){print(OUTF $MoveXLeftCommand);}else{print(OUTF $MoveXRightCommand)};
}
print(OUTF $MoveYCommand);
$YPosition++;
}
print(OUTF $BlackOffCommand);
print(OUTF $CyanOffCommand);
print(OUTF $MagentaOffCommand);
print(OUTF $YellowOffCommand);
close OUTF or die "Can't close $OutputFile: $!\n";
close INF or die "Can't close $InputFile: $!\n";
}

Dead simple really - a dumb microcontroller could handle this easily.

Publitime,

Go to the US Patent office web site. They have all the images and text related to all patents. Pixation also has a ton of detailed pictures of the parts of their machine and how they work. It's all there, but it is his patented design.

Steve

http://patft.uspto.gov/netahtml/search-bool.html <-patent search engine. i found the pixtion patents with their numbers, but didnt get frar reading them as their patent lawyer was fond of incomprehensible repitition of the same ideas. legalbabble is so obnoxious.

so. there is alot of info here now.. i gotta catch up!

sdfine - we are, at least not me, trying to copy the pixation design for ANY commercial purpose - not even sign making. i just like a challenge, love art, and want to have a crazy gantry-robot thing that can do wierd stuff like do additive 3d part creation using a can of that expaning insulation foam..

or draw a path with a gelatenus gasoline mixture, and then at the end light it... so a big complex design gets burnt into a workpiece.. thats the vector part.

for raster, large format art generation, even if it isnt a real photorealistic printer or whatever is very intriguing to some people.. every big r&d project probably involves some reverse engineering to investigate the existing technology.. thats part of why patents are wonderfull - they provide the entire technical details of an idea, while protecting it. this allows innovators to profit from their inventions, and it allows future innovators to build on what has been done, and not step on the toes of the creator of that technology.


this is very idealized of course. i have no patents, etc, so im sure any patent holders here would be very angry at any word of their ideas being reverse engineered, no matter how academic the goals..

i would NEVER try and commercialize a pilfered design.

besides, i think a smaller, more efficient, less complex painthead can be developed. something that uses little 15-25oz/in steppers, simple halfstep 2803 drivers, wire or plastic hoops instead of long wires and tensioning systems..

i havent started on this. for now, the airguns will be fun to do. im sure its been done many times in professional R&D projects. this idea - using air to blow in\paint onto a work surface is as old as art. literaly.

some of the first lasceaux(spelling?) cave drawings, in france, show evidence of a person crumbling up charcol, and blowing it on the back of their hand with their palm against a cave wall. this has left outlines of human hands 20,000 some years old....

i'm just intressting in the technik from the wirejet.
I will build a cnc painter just for fun.
Past year i have build a cnc mill for milling pvc for doing nothing with the machine.
3 years ago i bought a cnc for 125.000 euro's from mastermill.
This machine i use for commercial purpose.
Building cnc is my only hobby.
Mostly i use the parts again to rebuild something else.
So the cnc painter i will build as a hobby and not commercial.
For commercial printing i have a vutex large format solvent printer at my shop.
Building is just for fun and learning how technics works.

publi-exactly. i have access to all this stuff also. large format printers and good cnc equipment. i am mostly interested in the gantry for experimental art purposes. this thing, spinning on its axis, using random environmental inputs like audio and movement to make spirograph patterns in sand could be cool. or with a thick marker. or.. or. laying down layer by layer of insulation foam to make 3d sculptures. that could be the first reseach into large-format rapid prototyping. the design could go from something nasty and fun like foam to something precise and demanding like ABS pelets through a nozzle. i am sure something like that can be done on a diy scale. 20 years ago i doubt many CNC knowledgable people would have forseen rc airplane builders buying used linear motion components off ebay to build CNC machines in their garages - usually, it seems, much to the chagrin of their wives... hehhe. happily, i have no wife. :)

tachus 42

in what program you have write the controller?
Is it possible to use a PIC16F84A. microcontroller for the project.
What program do you use to assembler the program?
Is it possible to do it with MPLAB v5.70

publitime - that is a perl script. there is a perl compiler for PICs. i think its free? maybe im confusing it with another product i know exists, a perl basic stamp. so, those would work, but you would have to add the file transfer stuff for serial port, and write a pc program to work the thing. MPLAB is mainly for Assembler code, which is much much different than that perl code. that perl code, about 50 lines is probably hundreds of lines of assembler code. assembler for pics is good at simple stuff. there is a free C for PICs asembler, and for higherend PICs, microchip has free C compiler.

i use picbasicpro for my pic stuff. right now my board is dead though = gotta get a replacement to program chips.

Vacpress,

I understand you 100%. When I saw the pixelation web site I read every page on his web site and every patent he listed. Like you, when I see a piece of equipment like this my mind runs with all the possibilities. You have to appreciate the efforts of guys like Dean at Pixelation who has the knowhow to design, build and pull together the hardware and software for such a cool machine. His Wirejet chain chimbing machine is pretty cool too. I'm currently living in an apartment or I'd be building one right along with you.

sdfine

Vacpress,

My plan would be to use a single black print head (airbrush) and try printing black and white images first. I'm a Visual Basic programmer. In Vb I can load an image, read each pixel's color, interpret how long to spray the printhead to create that color (level of gray), move the X and Y axes to the first position and spray a dot. It would continue through this logic row after row until the image is complete. A more complex algorithm could be created to enlarge the image by spraying groups of dots for each pixel. It may be crude but it would be a start and the airbrus isn't that precise anyway. This would also be significantly easier than trying to find the information and learn how to create a standard print driver and interface to a RIP.

Steve

This link has Lots & lots of information about programming for control and graphics.. its fairly usefull seeming. lots of info about opensource projects...

http://www.orocos.org/related.html

The script a put up earlier was a perl scipt intended to run on the computer with Ghostscript and a GCode interperter as a quick and dirty way of getting some output. I wasn't suggesting to run perl on a microcontroller, I was just saying that it's easy to "decode" this file format.
publitime
A PIC16F84A almost meets the bill with 15 i/o pins two will be used for the crystal because i think you need acurate timing 2*4 for the steppermotors and 4 for the color jets there is on pin left and we need a least two for a serial port. Also it has no hardware serial port so you would need to bit bang the serial which could be a bit tricky when you are using the (single) timer for other stuff. It would be better to use a slightly "bigger" PIC.
I use AVRs and the gcc C compiler for stuff like this.

someone needs to write "easy RIP" that simulates a print driver, but actually is sort of like a "print driver macro language" which allows someone to write batch files, or other scripts which do the command-line style image processing with ghostscript to get the right image format, then does the perl script to convert into gcode or hpgl, then sends the file over serial to the pic that is the step generator. that way the thing would be very self cotnained, easy to rig... the hardest part would be making it work for more than very specific image setups.. i would imagine this thing could produce strange results... i am really really looking forward to seeing this thing scan a page like it thinks its a inkjet printer.

my dad has been in the laser printer repair industry for 15 or 20 years. he is going to flip when he realizes ive created a real printer from scrap... with help of course.

by the way, tachus and sdfine, your help is appreciated. i really hope i get this thing far enough along to reallt be able to need your skills. it seems like you guys can rig this software, to at least get me started with creating rasterized images... swell!