Re: [Gimp-print-devel] First experiences with an 870

[Robert L K. <rl...@al...>]

   Date: Thu, 18 May 2000 23:59:39 +0100
   From: Charles Briscoe-Smith <cp...@de...>

   I had imagined the interpolator to be a separate module, in the same
   way that the ditherers are.  Then the dithering code would pass the two
   lines bracketing its current position to the interpolator, and get back
   a line interpolated between them.  That assumes we're not going to use
   more than the four pixels surrounding any one point to determine the
   value of a point in between.  Maybe the more advanced interpolation
   algorithms use more surrounding points, in which case that wouldn't work.

Actually, as best as I can tell, all of the standard dithering
algorithms work on a row-by-row basis (even Raph's stuff).  There are
other ways to keep state around; that's what error diffusion does.

   Hmm.  The reason I was studying the weave code was because I was going
   to try to modify the weave pattern to make it print closer to the edges
   of the paper.  Since you've already done this, though, there's little
   reason for me to work on it too.  ;)

Other than the fact that the quality sucks at the top and bottom of
the page?  We do eventually hae to fix that.

   I noticed that your change to the weave pattern was much simpler than the
   way I wanted to do it.  It basically cuts off the top and bottom jets*sep
   rows and print them in a "naive" weave pattern, which unfortunately
   causes some patterning in that section of the print (on the 870 it's
   only really noticeable in fairly smooth areas like clear blue sky).

Likewise here.  I wish we only had to support the 870 :-)

   I've tried it, though, and I wasn't able to get it working.  This seems
   to be because of the assumptions that the softweave code makes.
   Specifically, it assumes that the last row of each pass occurs later
   than the last row of the previous pass.

There are a whole bunch of invariants it has to follow.  The most
critical one is that the virtual first row (where jet #0 would be
printing) of each pass must not be any earlier than the virtual first
row of the previous pass.  That's because the printer cannot space
backward.

I ALMOST got it working with a better pattern, but I didn't succeed.
The way to test this is to use escp2-weavetest.  It can take any
combination of jets, separation, passes, start and end rows, and
simulate the printer behavior.  It will tell you if there were any
errors and exactly where they were.

   > I won't put that one in tonight, but it's a good idea.  What's
   > SIGNULL, though?  I don't think it's POSIX.  Actually, you should get
   > a Sourceforge account and I'll add you as a developer.

   Sorry about the SIGNULL.  I put that there temporarily while I wrote the
   code intending to check it against the libc docs later.  When I checked,
   I found that signal number 0 doesn't have a constant defined for it, so I
   replaced SIGNULL with the literal 0.  I forgot to regenerate the patch,
   though.  Signal 0 is a signal that doesn't affect the target process
   at all; it just gives an error response from kill() if the process
   doesn't exist.  Its purpose is to enable you to see whether a process
   is still alive.  If it's no longer documented, there might be another
   way to do this now.  Actually I think I first read about it on SunOS,
   so maybe it's a SunOSism.

Actually, Linux does support that kind of thing, although it just uses
a signal number of 0.

   > If you're willing to get a Sourceforge account, let me add you as a
   > developer, and make the change on the other drivers (ps, pcl, and
   > Canon), go ahead.  It's not my favorite idea, but I must admit that it
   > would save some headaches in some cases.

   I've joined sourceforge, with username "cpbs".  I'll take a look at the
   other drivers, and see if I can do anything with them.  I doubt the PS
   driver will need any changes, since the postscript interpreter should
   clip to the printer's printable area.  I suspect PCL printers also clip.
   I'm fairly sure the Laserjet4 clips PCL commands: some years ago, when
   the LJ4 with its 600dpi was new, I hacked the (binary) laserjet driver
   of PageStream (an Atari DTP program) to do 600dpi output (and to do RLE
   compression when useful), and I think I saw the printer do clipping then.
   I don't know about Cannon.

Epson printers don't clip.  If you give it something wider than what
the printer can physically do, it will simply error out (or maybe the
print head will fly off the end of the printer and spill ink all over
your 1000 year old Persian rug).  If you give it something wider than
the paper, it will blithely dump ink all over the innards of the
printer.  Messy.

I've added you.

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
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