Thanks for the Plug...
Incidentally, we have another exciting project, we're taking on Spammers.
http://www.yoursite.co.uk/antispam/
(and)
http://www.yoursite.co.uk/antispam/test6.html
it's in dev at the moment ... not working yet.. but I'd like your comments
James
OS/2 Software @ yoursite.co.uk
We try to please
To whom it may concern.
I do have a prayer to all who write Websites.
In many cases it is necessary to keep a documentation for a given program to
use it as a reference during installation. Often Websites contain important information
that is written in HTML that wastes half a sheet of paper.
I usually print such information on my black and white Canon printer, and find
many websites are written with large areas of background or border frames that print
all in black on the inkjet machine. This is waste of costly ink.
Johannes Lomholt
There are six different colors that can print in each printed pixel, three from
each cartridge. And, they can overprint each other, so we can't just use three bits
and say "print color 0, or color 1, or ... color 5". We need six bits
for each pixel so we can use any combination of those six colors. I generalized
to one byte (eight bits) because that's what a hardware designer would typically
do. Then, in the firmware, for each nozzle the firmware can just scan that particular
bit of the appropriate byte and decide whether or not to print its color.
That's why it should only be one byte per pixel, not three. I explained that
when scanning you'd need three bytes for 24-bit color, but when printing you only
have 64 possible colors: each color can be on or off (you can't control the size
of the ink drop), so you have 2^6 possible colors, or 64 possible colors. It's dithering
that gives you the gradients, and a higher dpi gives you a less-obvious dither so
the image looks better.
There are only six nozzles per printed pixel. There are more nozzles on the ink
cartridge, of course, but they don't overlap. Each nozzle is dedicated to a certain
subset of the printed pixels. That speeds up the printing (you could make an ink
cartridge with only one nozzle, but then you could only advance the paper 1/1200"
on each pass, and it would print very slowly).
You say it's a CMY (actually, CMYK since black is stripped out) image going to
the printer. I don't think so; as I said, that eliminates many of your screening
options and only allows what's in the firmware. And that's unlikely, since then
you couldn't do smooth curves (such as when drawing a circle) because the circle
would be screened. The firmware has to allow for nozzle control.
Take another think on this. The translation must be done in the software driver.
Three bytes for the image pixel become one byte for the printed pixel. Only in a
thermal transfer printer, where each printed dot can be made any size you want (by
changing the heat), would you have three bytes per printed pixel.
Your tremendous swap file might have been caused (I'm guessing here) by the translation
of the source image size, not by its color depth. For example, if an image that's
2500 pixels wide must be printed on a page in a rectangle that's 3333 pixels wide
then there's a lot of interpolation that must be done. The interpolation uses a
lot of memory, but that's not a printer driver problem because if the image is the
correct pixel size to begin with then no interpolation is required.
Of course, the printer driver could have some poor coding in it, such as using
32-bit values to hold the 6 bits for each "printed pixel". If you have
an information file for the Lexmark with its printer command set, I could take a
look at it and see exactly what the format is for its input files (PCL is in hexadecimal
character, which doubles the file size right there).
Certainly, if I'm wrong please correct me. I'm always trying to learn, and I
like to ask questions.
- Peter Skye (pskye@peterskye.com)
Reply from Don Eitner, the author of the review of the Lexmark
Color Inkjet 5700 printer
The Editors of the VOICE Newsletter would like to thank Mr. Skye for his contribution
to making the VOICE Newsletter as accurate as possible. We appreciate the efforts
of OS/2 users who are active in their support. Peter Skye is a frequent contributor
to the SCOUG web site (http://www.scoug.com)
including his most recent article "A
Future Vision Warpstock is the Tomorrow of OS/2" - http://www.scoug.com/os24u/1998/scoug809.2.warped.html.