Re: Inkjet Driver for Chemcal Synthesis

(Sent that previous one too early; I was just in the process of
stripping out all the quoted printable stuff.)

   From: "Wayne Brooke-Devlin" <wbd@xxxxxxxxxx>
   Date: Fri, 23 Jul 2004 16:09:40 -0400

   At this point I became curious as to what the gimp-print driver was
   actually telling the printer to do. So I saved a hex dump of the driver
   output to file, and began parsing it by hand using Epson's ESCP2
   manual, the programming manual for the photo 960, your ESCP2 info, and
   anything else I could find on the subject. I now understand some of the
   remote mode commands (more than a few still appear undocumented), most
   of the ESCP2 commands (a few confuse me, perhaps we can discuss this
   later), but I'm rather lost when it comes to the actual data
   encoding. For instance, I would have expected my pattern of one dot
   every 6 spaces to be encoded as 82 08 20
   (1000/0010/0000/1000/0010/0000), but what I get is 92 49 24
   (1001/0010/0100/1001/0010/0100). Is this due to dithering? Or is it that
   I don't yet understand weaving?

This is weaving.  What's going on is that the printer cannot actually
deposit ink drops every 1/1440 of an inch; the best it can do is 1/720
inch if a single drop size is being used or 1/360 inch if variable
drop sizes are in use.  That isn't a problem, though, because the head
can be positioned with an accuracy and precision of 1/2880 inch.

At 1440x1440 DPI, the printer actually thinks it's in 2880x1440 DPI
mode, and it's using single size drops.  So in a single pass of the
head it's able to deposit drops every 1/720 inch.  If you're asking it
to print one position out of every 6 at 1440 DPI, that means it's
actually putting down a drop every 1/240 inch.  So that means that
during the pass it's printing this row it's putting down a dot at
every third position, which is what you've observed.
                                   
                                   (I'm working on
   understanding both) Also, the count byte for each row calls for (hex) 57
   or (dec) 87+1=88, 16 bit bytes, but a one inch row at 1440dpi would
   require 90*16 =1440 bytes.

Bytes are 8 bits, not 16.
                              
                              I do note that after the 88th byte the
   final 2 bytes do appear, although they are separated by 00's (ie
   92 00 49 00 24). I hope someone can give me a better grasp of the data
   encoding. It may seem odd to you that I looked at the hex output rather
   than your source code as a starting point here. In my defense, I can
   only say that I'm a chemical engineer who's done a good
   bit of work in instrumentation and control. So I'm a lot more
   comfortable with the assembly language of ESCP2 than I am with the
   higher level (C code?) of your drivers. It was only at the point where I
   saw how different the output data was from what I had expected that I
   began to recognize how much the drivers were massaging the input. I
   entered this project imagining that I might control the printer like an
   old 9-pin dot matrix printer. You know: move the head x move, the platen
   y, fire pins 1,5,7, etc. Oh boy! Was I wrong.

Unfortunately it's really not quite that simple.

   At any rate, the pre-dithered input problem appears to be of concern to
   me and several others here:

Fine.  I will add a pre-dithered correction mode.  For now it will
simply act like threshold mode, except that there will be no density
correction.  I actually coded it and tested it while writing this
message -- this was very simple.  The next thing I might as well do
for that is to add a special dither algorithm that doesn't really do
anything.

   Concerning Mr. Krawitz's second and fourth points, to me they
   appear somewhat related. I've tried taking one of my 1 by 2 inch
   printed blocks and re-feeding it through the printer for a second (over)
   print. I found very little displacement in drops between the first and
   second prints. For the most part, at least in the area where I had the
   desired separation, the second coat of drops appeared to be right on top
   of the first. I think this is referred to as very good registration.
   However, I haven't examined if the printer is capable of placing
   one colored drop directly on top of another during a single file
   printing cycle. This might be useful, but I don't think
   it's essential for what I have in mind. What I've been
   thinking of is a print file consisting of the initial remote and ESCP2
   commands followed by the data for my pattern. Then, rather than ejecting
   the page, the file would instruct the printer to reverse feed to the
   position at which it had started printing the pattern.

To the best of my knowledge, the printer can't reverse feed.  Your
trick below might work, but it might be just luck.
                                                          
                                                          Following the
   reverse feed the file would contain the data to reprint the pattern (or
   print another pattern) which would be followed by another reverse feed,
   and so on. I understand that Epson has eliminated the ESC j code for
   reverse feeding, however I found a reference (I think in one of the
   Epson manuals) to a set of paper feed values that allow for up to =C2=BD
   inch of reverse feed. (I guess I'm going to have to find that
   reference and make sure it works. I seem to remember it had to do with a
   number exceeding a certain value being interpreted as negative. It made
   sense when I read it anyway). You can see now why I've been
   working with a block =C2=BD inch high.

-- 
Robert Krawitz                                     <rlk@xxxxxxxxxxxx>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@xxxxxxxxxxxx
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click