Menu
▾
▴
Re: [Gimp-print-devel] First experiences with an 870
|
From: Robert L K. <rl...@al...> - 2000-05-13 03:22:19
|
Date: Sat, 13 May 2000 03:20:47 +0100
From: Charles Briscoe-Smith <cp...@de...>
If Eric isn't able to do this, I'm willing to give it a go sometime.
I think it would be best to co-ordinate with Ben Gertzfield
<ch...@de...> since he maintains the Debian gimp packages.
Since /usr/lib/gimp/1.1/plug-ins/print already exists in gimp1.1,
either gimp-print should be included in that package in place of the
print plugin currently in gimp1.1, or a separate package would have to
divert (or possibly replace, but that's rather ugly so I'd rather not)
the gimp1.1 print plugin. (There's little point packaging it for gimp
1.0 even if it compiles with it; gimp 1.0 users want stability...)
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.
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.
> See above about the tiny dots. It might also be (barely) noticeably
> different in things with very sharp transitions or very fine lines.
I tried a picture of a cactus. The 1440x720DPI softweave gives
better-defined results than 720DPI softweave in the case of a light
cactus needle against a dark background. For a dark needle on a light
background, there was nothing to choose between the two.
That's not altogether surprising.
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.
The 360DPI mode is little light with density 1.0 and 720DPI microweave
is a little dark, but it's quite close. The microweave modes are still
really bitty. The driver doesn't seem to be using variable sized dots
when in microweave mode. Still, as you say, there's no reason to use
these modes on the 870.
Right. What I should do is flush that on the 870 (or for that matter
on almost all of the new printers).
> 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.
> 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.
The page is rendered to a collection of dots by the dithering code at some
resolution, e.g. 720x720DPI. A "row" consists of all the dots output
by the dither for printing at a single vertical position. A row may be
printed in two or more "subpasses" which print dots at the same vertical
position but different horizontal positions. I suppose this is needed
if the printer's "raster image" command doesn't allow a high enough
horizontal resolution, or if the print head can't print dots as close
together as we'd like (I know the old dot matrix printers used to ignore
any dot immediately following another dot on the same pin). I'll call a
subpass (or a row if it's printed in only one subpass) a "line": a line
consists of all the dots printed by a single nozzle during one pass.
That's basically correct. The other reason to do this is simply to
force more different jets to print the same line. This reduces
banding. Typically the jets aren't all of exactly the same size; some
are slightly bigger (darker) and some slightly smaller (lighter).
Using more subpasses uses different jets on the same row, which tends
to average things out.
A "pass" is a group of lines printed in one sweep of the print head.
In a pass, each jet on the printhead can be assigned one line, so these
lines must be spaced the same way as the printhead's jets. If jets
at the top of the pass lie outside the image, they are assigned blank
"phantom rows". Unused jets at the bottom of the pass don't need phantom
rows, because of the way the printer's "raster image" commands work.
Correct.
initialize_weave() creates a data structure which keeps track of the
weaving pattern for a single page, and destroy_weave() cleans it up
afterwards. As each row on the page is dithered (in order, top-to-bottom)
the row is passed to escp2_write_weave(). This calculates the weave
parameters for that row, chops the row up into lines as necessary, and
stashes the lines in the softweave data structure. When all the lines
for a given pass are available, escp2_write_weave() advances the paper
appropriately and prints the pass.
Again, correct.
initialize_weave() takes parameters:
jets: number of nozzles in printhead.
sep: separation between nozzles in rows (1/720").
osample: number of passes necessary to print a single row
(due to the row's resolution being higher than the
printer's horizontal resolution).
v_subpasses: number of passes in which to print each "osample"
pass in order to bring different jets into play.
v_subsample: number of dithered rows for each printed row.
I'm not sure what this does. Does it merge rows?
Overprint them? Feed the paper in smaller increments
than 1/720"?
colormode: one of: monochrome, four-colour or six-colour printing.
width: number of bits per pixel.
linewidth: number of pixels per row.
lineheight: number of rows on the page.
separationrows: used for calculating paper advance for the 1520/3000.
I'm not sure what this does, and I doubt I need to
know at the moment.
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.
Parameters calculated by initialize_weave():
OVERSAMPLE is the number of lines to be printed on each row.
VMOD is the number of lines to be printed in the space between each
pair of jets. In other words, it's the number of passes the printhead
makes while spanning any given point on the paper.
NJETS is the number of jets within whose span we print one line on
every row as the printhead moves that distance. That is, a line is
printed on a given row once for each time NJETS nozzles move past it.
So, in the space of NJETS nozzles, we have to do a complete weave
pattern, hitting each row once. The first NJETS nozzles print each
row for the first time. The next NJETS nozzles overprint each of
those rows to perform the second subpass, the third NJETS nozzles
print the third subpass, etc. Thus, we only need consider the first
NJETS nozzles when working out our weaving pattern; the rest of the
jets simply trail behind at regular intervals.
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.
WEAVEFACTOR is the interleave factor, NJETS/SEPARATION rounded up.
Each pass, WEAVEFACTOR lines get printed below the previously
lowest-printed line. (This is a guess; I don't understand it yet.)
That's right. It's also the source of some problems. It makes it
impossible to go to an x8 weave pattern on (32, 8) printers (32 jets,
8 separation), and it prevents the 440 from printing at any kind of
improved weave pattern.
> The problem is that the Gimp hits plugins with a SIGKILL (kill -9)
> whenever you hit cancel, so there's no opportunity to clean up (Sven,
> are you listening?)
I've tried fixing this; here's the patch. It works by spawning a
"monitor" process whose purpose is to spawn lpr and then watch its parent
process (the plugin). If the parent sends SIGUSR1 to the monitor process,
the print job was successful, so the monitor quits. If the plugin dies
before sending SIGUSR1, the monitor kills off lpr, thus cancelling the
print job.
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.
[The yellow colouring of the pictures I printed]
> Did that seem specific to the camera?
I haven't really tried enough image sources to be able to tell. I'll try
some scanned photos sometime.
I got that from my 870, also, so I think it's genuine.
> The driver is very well tuned for the 700 (I previously had an EX).
Ben uses Windows and the Windows driver with his 700. The prints we
did for him were from the 870 with gimp-print. What I meant to say
(apparently unsuccessfully) was that (Photo 870 + gimp-print) makes better
prints than (Photo 700 + Windows driver), which seems to be a good result,
since the 700 is relatively recent. I also know first-hand that (Photo
870 with gimp-print) is considerably better than (Colour 3000 with Windows
driver), which is also a good result, but probably not a surprising one.
I would hope so. For that matter, I would hope that people prefer
output from the 700 with gimp-print over a 3000 from Windows. The
light inks really help.
I'll append the patch for clipping the image to the page size that I
mentioned in my previous email. In landscape mode, 3.1.4 with this
patch seems to print images upside down... But as far as I can tell,
vanilla 3.1.2 did the same thing.
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.
--
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
|
