I speak from the perspective of someone who's actually written (or rather, very extensively modified and adapted) drivers for a lot of Epson inkjets. Basically, all of the Epson inkjets (and, for that matter, most if not all of other the low-end, high quality inkjet printers) are completely dumb raster devices. You give the printer input dots and it lays 'em down. The programming's actually a bit more complicated than that, because the dots have to be presented in a rather funky order (at least on Epson printers), but the rendering is done precisely for each and every dot. Date: Wed, 14 Jun 2000 06:31:13 +0100 From: "Michael D. Garrett" <garrettmd@chartertn.net> Regarding the fundamental problem of representing many tonal variations on 4color printer with basically two states (on/off) per color: A lot of modern inkjets can represent considerably more than two states, with variable dot sizes and light magenta and light cyan inks, but the general principle remains -- the number of levels needed to represent the tonal range far exceeds the number of states per dot position. 1) Do halftone concepts apply to inkjet printing (without an interceding RIP)? The Windows driver doesn't appear to (visual inspection), and the driver I work on (a free software/open source one for the Gimp and Ghostscript) doesn't use halftoning. A driver could certainly do that if it wanted to, although with a maximum resolution of 1440x720 dpi, the screen would be quite coarse. What happens instead is a dither is used to achieve an appropriate dot frequency while spacing the dots as evenly as practicable to achieve a smooth appearance. I guess this depends upon what you mean by "halftone concepts" -- certainly tonal variation is accomplished by varying the amount of ink deposited on the paper, but it's not done by varying the size of the drops (there may be a limited number of choices of dot sizes, which dramatically improves quality, but there's not the smooth variation that halftoning does). 2) if halftone dots are not generated from the pixel image, how is tonal variation simulated? a) how is a 300 pixel/inch image transformed into a 720 dpi print? Usually by "sampling" the image at 720 dpi and dithering each point. This, of course, means that each image pixel can be sampled more or less than once. An individual driver could do what it pleases; it could interpolate before dithering, for example. b) if I send a photo scan to an inkjet printer with default print settings, does it basically dither the pixels. c) Do I have control over the dithering algorithm? That depends upon the driver, or you could write your own to use any dithering algorithm you please. The gimp-print driver does offer an explicit choice of dithering methods, partly because it's still under development. 3) I've read that inkjet printers 'require' RGB input. That they have conversion tables optimized for the printer. And sometimes for the paper, and the particular inks, and the phase of the moon :-) a) Where is that conversion done, in the driver or in the printer? Driver. As I stated above, the printer has no intelligence. We're looking at allowing CMYK input to the gimp-print driver, but it won't be that useful right away because there really isn't much if any software under Linux/UNIX that generates CMYK separations. But Ian Young (also on the list) has talked about a Photoshop plugin based on the gimp-print software that *would* use CMYK input. -- Robert Krawitz <rlk@alum.mit.edu> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lpf@uunet.uu.net Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton - Please do not include an entire message in your response. Delete the excess. http://www.leben.com/lists for list instructions.