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

[Charles Briscoe-S. <cp...@de...>]

[ As you can see, I don't reply to my email very promptly...  Sorry. ;) ]

On Fri, May 12, 2000 at 11:24:13PM -0400, Robert L Krawitz wrote:
> 
> Well, 3.1.4 is probably at least as stable as the plugin in gimp 1.0
> (version 2.0.2), and it supports far more printers at much higher
> quality.  It could be thought of as a midlife kicker.

If it's optional, it would probably be OK.  I suppose Debian has
a stricter idea of stability than most...  I've thrown together a
gimp-1.1-print Debian package, which seems to work on the machines here.
It depends on "yada", the packaging helper which I wrote and have been
failing to properly maintain over the last year.  I hope this won't
cause anyone any problems...

I think Eric's work is on a gimp-printified ghostscript package; mine
is on a gimp plugin package.  So the two should be complementary.

>    BTW, I noticed that gimp-print puts its printrc in ~/.gimp rather than
>    ~/.gimp-1.1.  Why's that?  (In preparation for gimp v1.2, perhaps?)
> 
> Not on my system, it doesn't.  It asks the gimp where to find its .rc file.

And, as if on cue, my last couple of builds have gone back to using
~/.gimp-1.1.  Spooky.

>    Something that I thought might be useful would be interpolation.
>    The dither routine could be supplied with the row before the current
>    position and the row after, and could interpolate the colour of its
>    current location from the surrounding pixels.  This might be desirable
>    when scaling up an image a lot, so that the low resolution of the original
>    image does not cause ugly pixellation in the printed output.  This would
>    have to be an option, of course, since it would only be appropriate for
>    some kinds of images, like photos.
> 
> I've thought about this.  It would require a major change in the
> architecture -- give the dithering routine a line, and have the
> dithering routine call back into the driver.  That's a good
> architecture, but it would take a fair bit of work.  Besides, it would
> probably be very slow.  I don't know if Raph's code requires something
> like that; if it did, it would be a good impetus for it.

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.

For a simple linear interpolation between the four pixels surrounding the
current point, it shouldn't need much of an architectural change, IMO.
However, given the long-term goals you've described for gimp-print,
this should probably not be done in the code we're working on here.

>    > I have the same problem (kernel 2.2.10).  What kernel are you running?
> 
>    2.2.14.  Is USB likely to be faster?  I don't remember what USB's transfer
>    rate is supposed to be.  The machine has a USB port, and, IIRC, Linux
>    2.2.15 does USB.
> 
> No idea.

I downloaded the patch for 2.2.15, and it doesn't appear to have any USB
code in it.  What 2.2.15 does add is I2O support.  Bang goes that idea.

>    > That's an attempt to correct for the starting vertical position thing
>    > you noted below.  I don't have that quite right.
> 
>    This patch seems to fix it; the comment says how I think it does so:
> 
> It's also obsolete (or will be, as soon as I check in my latest
> stuff).  I've figured out how to print all the way to the top edge and
> to about the bottom 5/16".  I could probably even closer if I tried.
> I've been spending all evening testing it and writing yet more test
> cases.  It's painful.  It may not work absolutely correctly for 360
> dpi and microweave (particularly the bottom of the page).  I'll
> probably check it in tonight even if it isn't 100% tested; it's useful
> enough so it's worth getting out there.  The Ghostscript users will be
> very happy about this.
> 
>    I've spent a day or two so far teasing apart the weave code, and I'm
>    *pretty* sure I know more about how it works than when I started...
>    It's hairy stuff, though.  It's going to take a while longer before I
>    understand it.
> 
> It's going to be even worse after tonight.

(Actually, I could understand those changes quite easily.  Much of the
rest of the code is still a mystery...)

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.  ;)

> There are a few more parameters in the stuff I'm about to check in.
> Those should be fairly obvious.  The separationrows thing probably
> isn't needed in softweave, but I don't have a 1520 or 3000 handy to
> test, so I haven't enabled softweave for it.

We have a 3000, so I could try testing stuff on it if you like.  (But as
you might've noticed, my response time it not guaranteed to be fast...)
It's hooked up to my dad's Win95 box, but that shouldn't cause too
many problems.

> Well, except for the phantom row issue.  Also, the stuff that lets me
> print to the edge of the page needed some changes to the weave pattern
> in those areas of the page in order to work.

Indeed.  This is what I was planning to change, too.

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).
The few passes next to that section don't use all the nozzles on the
print head.  If you took all the print lines which could be printed in
the normal weave pattern and transferred them from the "modified" passes
to the "normal" passes, you'd have approximately what I was planning,
which would probably reduce the patterning.

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.  I think my code didn't work
because it violated that assumption.  (It may also assume that there are
no empty passes, but I'm not sure.)  If I ever work out how all those
complicated formulae generate that nice weave pattern, I might be in a
position to fix this...  ;)

> 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.

> 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.

Cheers,

-- 
Charles Briscoe-Smith             <URL:http://www.debian.org/%7Ecpbs/>
PGP2:  1024/B35EE811  74 68 AB 2E 1C 60 22 94  B8 21 2D 01 DE 66 13 E2
"You think that's air you're breathing now?" -- Morpheus, "The Matrix"