gimp-print-devel

[Gimp-print-devel] Re: Color Printing on Epson printers

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

   From: Leonard Evens <le...@ma...>
   Date: Tue, 9 May 2000 10:05:49 -0500 (CDT)

   Entering directory `/home/src/print-3.1.3'
   /bin/sh ./mkinstalldirs /usr/local/bin
     /usr/bin/install -c  unprint /usr/local/bin/unprint
     /usr/bin/install -c  escp2-weavetest /usr/local/bin/escp2-weavetest
     /usr/bin/install -c  pcl-unprint /usr/local/bin/pcl-unprint
   /usr/local/bin/gimptool --install-admin-bin print
   /usr/bin/install -c print /plug-ins/print
   /usr/bin/install: cannot create regular file `/plug-ins/print': No such file or directory
   make[1]: *** [install-libexecPROGRAMS] Error 1
   make[1]: Leaving directory `/home/src/print-3.1.3'
   make: *** [install-am] Error 2

Huh.  I wonder if gimptool is doing something bogus.  What version of
the Gimp are you running?

   The plug-ins directory is 
   /usr/local/lib/gimp/1.1/plug-ins
   and I just copied print there.  It looks as if there might be a
   missing prefix somewhere.

That's the correct workaround.

   What are the three files which were created for?   And what does the
   gimptool line accomplish?

unprint, escp2-weavetest, and pcl-unprint are some debugging tools.
Gimptool is a script that does a whole bunch of gimp admin things.
gimptool --install-admin-bin installs a plugin into the central plugin
directory.

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

Re: [Gimp-print-devel] Another ink question

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

   Date: Tue, 09 May 2000 11:12:23 +0100
   From: Dave Hill <da...@mi...>

   Apparently, the black and colour cartridges used simultaneously
   in the Deskjet 550C and 560C have incompatible chemical makeups,
   and they should not be mixed at a given print point.

   On the other hand, the newer ones used in the DJ600 series can
   be mixed with no ill effects.

   How would you set the dither knobs to differentiate between
   these two cases. I think it has to do with "set_black_upper()",
   and what is the default action.

The way to handle that is to not pass a black bit vector (pass a NULL)
if you don't want black ink.  I haven't tested this in a while, but
that's how it's supposed to work.

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

[Gimp-print-devel] Another ink question

[Dave H. <da...@mi...>]

Hi Robert,

Another "ink" question for you.

Apparently, the black and colour cartridges used simultaneously
in the Deskjet 550C and 560C have incompatible chemical makeups,
and they should not be mixed at a given print point.

On the other hand, the newer ones used in the DJ600 series can
be mixed with no ill effects.

How would you set the dither knobs to differentiate between
these two cases. I think it has to do with "set_black_upper()",
and what is the default action.

Dave

-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
				davehill at users.sourceforge.net
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

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

[<sh...@al...>]

> BTW, since you're a Debian developer and there are a number of people
> here interested in how to package this up for Debian, how would you
> like to become a developer on this project?  If you'd like to, just
> get yourself an account on sourceforge.net and drop me a note.  We
> need someone to create .deb's (as well as rpm's).

I'm working on the .deb's in what spare time I have.  I've never actually
created .debs before except in a few trivial cases (such as pine)
but the scripts needed are essentially already written.  I just need
to figure out what I'm doing and do it.

I'm heading back to Japan in 8 days and I want to make sure that
I can get everything set up properly on my machine at home before I
leave.  That's the time scale I'm looking at.

Eric

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

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

Nice stuff.  BTW, you can generate diffs with 'cvs diff -u'.

BTW, since you're a Debian developer and there are a number of people
here interested in how to package this up for Debian, how would you
like to become a developer on this project?  If you'd like to, just
get yourself an account on sourceforge.net and drop me a note.  We
need someone to create .deb's (as well as rpm's).

   Date: Tue, 9 May 2000 00:03:54 +0100
   From: Charles Briscoe-Smith <cp...@de...>

   I used the CVS version of gimp-print as of late evening UK time Thursday
   (4th May).  I did try 3.1.2 first of all, since I already had it
   installed, but the results weren't much good.  gimp-print has improved
   a lot since then.

That should be pretty good, although the 3.1.4 release might be
slightly better (or it might not).

   (Incidentally, I can't see anywhere in the ESC/P2 code path where the
   "glossy film" setting actually affects anything...  print-escp2.c sets
   use_glossy_film=3D1, but the only place that it's used says:

     if (use_glossy_film)
       dither_set_black_upper(dither, 1.0);
     else
       dither_set_black_upper(dither, 1.0);

   Was there once some difference here?)

Yup.  BTW, that's one major difference between the version you pulled
and the current source.  The current source uses .999 as black_upper.
That means that pure black will be printed using only black ink.  1.0
allows some color ink to mix in.

   The first thing I did was to increase the density, since black areas
   were showing flecks of white paper.  Density of 1.5 seemed enough to
   fill in the gaps, and brought the overall image brightness down to
   about the right level.  (I was using a scan of a Kodak colour test card
   at this point.  I also printed a set of CMYK fountain fills, and the
   results were fairly even.  The test card scan and the fountain fills
   were the only images I've used so far that did not come from the D1.)

I've also found that 1.5~1.6 works well with these printers.  I'd like
to find out exactly what printers work well at that setting, and then
change them in the printer parameter list (printers.xml).

   At this point, I went outside and photographed some plants (we had nice
   sunny weather in London that day, for a change).  I printed these at about
   2"x3", with good results.  The prints really look (to me) like standard
   optical/chemical prints from any viewing distance more than about 4
   inches, although looking back at those prints now, I can see that they
   are not the correct colour (somewhat too yellow).  I've spent quite some
   time twiddling the colour balance, but I haven't got it right yet.

Jean-Marc has been doing some work in this area.  Unfortunately, I
bollixed him well and truly by changing all the dither stuff between
3.1.2 and 3.1.3.

		  Time to  Render     Print
			   ------     -----
   1440x720DPI softweave:  34sec      2min 14sec
   1440x720DPI enhanced:   50sec      4min 20sec
   1440x720DPI microweave: 34sec      25min (that's not a typo!)

       As well as taking 25min to print, this one looked awful.  Too dark,
       grainy and fuzzy, and looking as if the image had been quantised
       to just a few levels of intensity before printing.  There are also
       diagonal lines visible in the dark areas.  A softweave print of the
       same picture was excellent, with every vein in the leaves clearly
       defined and good colour tones.  Looking at the highlights with an
       eyepiece, I think maybe the wrong dot size is being used.  It looks
       like normal size dots are being printed where small dots should be.

The microweave modes are almost useless with this printer.  They're
also evidently done incorrectly.  You might find that a density of 1.0
will work well in the microweave modes (if it matters, which it really
doesn't, since those modes really don't offer anything of interest).

1440x720 enhanced renders at 1440x1440.  On my Photo EX, that improves
things quite a lot.  Maybe it doesn't matter on the 870, which has
such tiny dots to begin with.

   720DPI high quality:    30sec      2min 14sec

I would expect that that would render much faster than 1440x720, since
it only generates half as many dots.  You might like to try 720 softweave.

   Full A4 (with my clipping patch (see later)):
   1440x720DPI softweave:  5.5min     13.5min
       (This was before I discovered that 720 softweave gave virtually
       indistinguishable results in less than a third of the time!)

See above about the tiny dots.  It might also be (barely) noticeably
different in things with very sharp transitions or very fine lines.

   1"x1.6":
   360DPI:                 3sec       7sec
       Dark, grainy, too magenta, but fast.

Try a density of 1.0 here.

   720DPI microweave:      6sec       34sec
       Much, much too dark.  The printer dumped so much ink on this one
       that the photo paper actually went slightly soggy, something I
       never expected to see (although it didn't actually soak through to
       the back).

Again, try a density of 1.0 here, and don't bother using this mode.

   720DPI softweave:       6sec       24sec
       Good.  Bidirectional printing, so it was pretty fast, and I'm
       surprised this didn't affect the print quality.  When I print a
       more complex full A4-width image in this mode, the printer pauses
       at the end of each pass, presumably waiting for more data.  It looks
       like the parallel protocol is the bottleneck in this mode.  I tried
       setting the parport to ECP and EPP mode, and giving Linux the DMA
       channel for this one, but wasn't able to speed it up any.

I have the same problem (kernel 2.2.10).  What kernel are you running?

   In summary, the softweaves, high quality and enhanced were all equal best,
   while 360DPI and the microweave modes were each pretty awful.  Oddly,
   the two microweaves and the 360dpi each printed half a millimetre lower
   on the page than the other four modes.

That's an attempt to correct for the starting vertical position thing
you noted below.  I don't have that quite right.

   I guess the weave normally starts printing with the bottom nozzle.
   Assume we're advancing the paper by x each pass, the nozzle separation
   is s, and assume that x > s.  We can instead start printing with the top
   nozzle and advance the paper by (x - s) until the weave has expanded to
   use all nozzles, then start advancing by x as before.

The difficulty is that in some of the high resolution modes that
assumption is incorrect (in some cases, it advances by as little as
one row sometimes -- the actual advance varies).  If you want to play
with this, check out the test program 'escp2-weavetest'.  This (in
combination with run-weavetest) is a regression test for the weave
code, that checks a whole bunch of invariants very carefully.  It's
really hard to get it all right, but if you want to take a crack at
it, please do (it would be a really worthwhile contribution).  Right
now it does something that works correctly, at the cost of losing the
top and bottom of the sheet.

   (In the 870's Windows driver, selecting "maximum printable area" instead
   of "standard printable area" results in a little pop-up box warning:
   "This setting allows you to extend the printable area, but print quality
   may decline in the expanded areas.  Do not select this setting if you are
   printing on Premium Glossy Photo Paper.")  If we could adjust the weave
   pattern to give the same margins without advancing the paper so far,
   it should improve print quality near the trailing edge of the page.

That's interesting.

   (Of course, if it's possible to reverse-feed the paper before starting
   to print at the top margin, it might not be necessary to do this weave
   compression at the leading edge, but it would probably still be desirable
   at the trailing edge of the paper.)

It's not possible to reverse feed.  At least, it isn't documented, and
I've never seen a Windows print file that suggested that it is.

   One other thing:  If I press the "Cancel" button during rendering,
   the data that has already been piped into lpr gets printed anyway.
   This should not happen.  However, I'm not sure how it should be fixed
   short of writing to a temp file and then passing this to lpr later,
   and that would be bad because a full A4 print can produce a spool file
   of up to 90MB.  Perhaps gimp-print should send a signal to lpr to kill
   it if the user hits "cancel"?

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 think this depends on the source image really.  A friend asked for
   four images to be printed today, and we used a brightness of about 75,
   red=3Dblue=3Dgreen=3D100 and density=3D1.5.  For images from our camera, th=
   at
   seems to be too yellow, and the brightness doesn't need to be reduced...

Did that seem specific to the camera?

   > 2) The ink dries very slowly.

   I didn't find this.  I used the ink that came with the printer, and Epson
   A4 Photo Paper.  I haven't yet managed to smudge a print.  In fact,
   I put one print through upside down to try a black and white print on
   the back, and the print on the front seems unaffected.  I didn't manage
   to smudge the printing on either side.

Hmm.  Maybe I should use genuine Epson paper :-)

   > 3) Pale tones are very good indeed.  Gray is very neutral.  However,

   I agree.  The fountain fills I printed are very smooth.  Looking again,
   the grey goes very slightly green between about 35% and 75% black.

That seems to be a common theme.  It's much less than it is on the
Photo EX, and the driver is much better tuned for the EX.

   > 4) Mid and dark tones are grainy.  It's less obvious when I push the
   >    density up.  It might be a sign that the dither algorithm has
   >    problems here; it might also simply be a sign that the density is
   >    too low.  The grain looks a little bit like "shadowing" from large
   >    dots, but not entirely.

   I'm not sure I've seen this.  Very dark areas occasionally "black out",
   but gimp-print does this far less than the Windows driver does when
   printing to our ESC3000.

Huh.  That's interesting.  Look at dark yellows carefully.

   Well, I've probably bored you for long enough now.  Thanks for reading
   this far.  ;)

Certainly not (the former).  That's how we get new ideas.

   And thanks for all the work you (all) have already done on gimp-print!
   I mentioned above that a friend (a newspaper photographer) had asked
   for some images printed.  He has a Photo 700 (and no ink at present) and
   uses Windows (NT I think).  After seeing the prints gimp-print produced,
   he said he wanted a new printer.  Congratulations!

The driver is very well tuned for the 700 (I previously had an EX).
It's not a bad printer, even if the dots are a bit coarse and it's
hard to balance the colors precisely.

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

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

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

Hello all,

I'd better introduce myself.  I'm Charles Briscoe-Smith.  I recently
finished a PhD thesis in computer science, and am waiting to do my exam.
In the mean time, I'm helping my sisters turn their photography business
into a digital photography business.  I built them a PC, installed Debian
on it (well I'd have to, wouldn't I?  I'm a Debian developer!), advised
them on buying a digital camera, and have finally got them a printer.
When we have a UPS, we should be ready to rip the minilab out of their van
and replace it with the PC and printer.  Then, when they go to photograph
at horse shows, they won't have a delay of half an hour between getting
the film back to the van and being able to show people their pictures,
and this should result in more sales.

About 1.5 weeks ago, we ordered an ESP870.  It arrived on Friday,
since when I've been testing it with gimp-print, (and testing gimp-print
with it), and I've just come up for air. ;)  (In the meantime, it seems
everyone else on this list has also acquired an 870...  Hello Jean-Marc!
Hello Robert!)

The results are pretty impressive.  I'll go through what I've done and
what I've found; let me know if this is of any use.

I used the CVS version of gimp-print as of late evening UK time Thursday
(4th May).  I did try 3.1.2 first of all, since I already had it
installed, but the results weren't much good.  gimp-print has improved
a lot since then.

My main tests were all on Epson A4 Photo Paper (not the "Premium Glossy
Photo Paper" that came in the sample pack supplied with the printer)
and with the Epson "Intellidge" ink that came with the printer.  I used
quite a few different images, mostly taken with a Nikon D1 digital
camera on "normal" quality.  (All the images that that camera produces
are 2000x1312; the quality setting adjusts the degree of compression.
"Normal" gives JPEG files of about 600KB.)

I started with gimp-print's default settings, changing paper type
to "glossy film", ink type to "variable dot size" and resolution to
"1440x720DPI Softweave".  This gave prints that were not too bad, but
were rather light and desaturated.

(Incidentally, I can't see anywhere in the ESC/P2 code path where the
"glossy film" setting actually affects anything...  print-escp2.c sets
use_glossy_film=3D1, but the only place that it's used says:

  if (use_glossy_film)
    dither_set_black_upper(dither, 1.0);
  else
    dither_set_black_upper(dither, 1.0);

Was there once some difference here?)

The first thing I did was to increase the density, since black areas
were showing flecks of white paper.  Density of 1.5 seemed enough to
fill in the gaps, and brought the overall image brightness down to
about the right level.  (I was using a scan of a Kodak colour test card
at this point.  I also printed a set of CMYK fountain fills, and the
results were fairly even.  The test card scan and the fountain fills
were the only images I've used so far that did not come from the D1.)

At this point, I went outside and photographed some plants (we had nice
sunny weather in London that day, for a change).  I printed these at about
2"x3", with good results.  The prints really look (to me) like standard
optical/chemical prints from any viewing distance more than about 4
inches, although looking back at those prints now, I can see that they
are not the correct colour (somewhat too yellow).  I've spent quite some
time twiddling the colour balance, but I haven't got it right yet.

I tested the various resolution/weave settings for both rendering time,
printing time and appearance.  Rendering time is for a 400MHz K6-II.

Printing a 2"x3" photo from a 2000x1312 jpeg:

               Time to  Render     Print
                        ------     -----
1440x720DPI softweave:  34sec      2min 14sec
1440x720DPI enhanced:   50sec      4min 20sec
1440x720DPI microweave: 34sec      25min (that's not a typo!)

    As well as taking 25min to print, this one looked awful.  Too dark,
    grainy and fuzzy, and looking as if the image had been quantised
    to just a few levels of intensity before printing.  There are also
    diagonal lines visible in the dark areas.  A softweave print of the
    same picture was excellent, with every vein in the leaves clearly
    defined and good colour tones.  Looking at the highlights with an
    eyepiece, I think maybe the wrong dot size is being used.  It looks
    like normal size dots are being printed where small dots should be.

720DPI high quality:    30sec      2min 14sec

4"x6":
1440x720DPI softweave:  1min 50sec 5min

Full A4 (with my clipping patch (see later)):
1440x720DPI softweave:  5.5min     13.5min
    (This was before I discovered that 720 softweave gave virtually
    indistinguishable results in less than a third of the time!)

1"x1.6":
360DPI:                 3sec       7sec
    Dark, grainy, too magenta, but fast.

720DPI microweave:      6sec       34sec
    Much, much too dark.  The printer dumped so much ink on this one
    that the photo paper actually went slightly soggy, something I
    never expected to see (although it didn't actually soak through to
    the back).

720DPI softweave:       6sec       24sec
    Good.  Bidirectional printing, so it was pretty fast, and I'm
    surprised this didn't affect the print quality.  When I print a
    more complex full A4-width image in this mode, the printer pauses
    at the end of each pass, presumably waiting for more data.  It looks
    like the parallel protocol is the bottleneck in this mode.  I tried
    setting the parport to ECP and EPP mode, and giving Linux the DMA
    channel for this one, but wasn't able to speed it up any.

720DPI high quality:    6sec       1min 15sec
    Good.

1440x720DPI microweave: 8sec       11min 55sec
    Slow, dark, grainy and much too magenta.

1440x720DPI softweave:  9sec       1min 15sec
    Good.

1440x720DPI enhanced:   19sec      2min 25sec
    Good.

The four marked "good" are practically indistinguishable from one another.
Guess which one I'll be using for now?  ;)

2.5"x3.8":
720DPI softweave:       23sec      55sec
720DPI high quality:    25sec      2min 52sec
1440x720DPI softweave:  39sec      3min 5sec
1440x720DPI enhanced:   1min 20sec 5min 35sec

In summary, the softweaves, high quality and enhanced were all equal best,
while 360DPI and the microweave modes were each pretty awful.  Oddly,
the two microweaves and the 360dpi each printed half a millimetre lower
on the page than the other four modes.

I mentioned my clipping patch: I tried printing a image at full A4 size.
I switched "scaling" to PPI, then reduced the PPI just until the left
and top margins both became negative.  This way, I reasoned, the image
should fill the entire printable area of the page, but would be clipped
somewhat at the top.  It didn't work; the printer just sat and flashed
its power light...

Looking in the print file, I found that the driver was trying to
make the printer print outside its imagable area (in particular, it
had an odd-looking parameter for the first "ESC ( v"), so I patched
print-escp2.c to clip the image appropriately before passing the data
to the dithering routine.  I don't use CVS very much, so I'm not sure
how to generate a diff against the repository; I'll read up on it and
make a patch sometime.  (I also made a few other changes, like adding an
"A5 landscape-way" paper definition and maybe other stuff I've forgotten,
so I wouldn't want to commit the changes myself.)

After making the changes, I realised that what I did was probably not
the best way to fix the problem.  Better would be clipping at a higher
level, before the printer command language-specific code is called.
And it's probably already done when the driver's used in ghostscript mode.
But it fixed things for me, and made me somewhat familiar with the code.

I've found that when printing at 360DPI, the top margin seems to be almost
nonexistent (perhaps 0.2mm), but with 720 softweave or 1440x720 softweave
it's just under 0.4 inches.  If I read the definition in print-escp2.c
right, 0.4 inches is the distance between the top and bottom nozzles on
the 870 (at least as far as gimp-print is concerned).  I think this means
that the weave algorithm must start by printing with the bottom-most jet,
then allow the weave pattern to move up until it reaches the top jet.
I've watched the way our ESC3000 (driven by the windows driver) prints
close to the bottom margin, and it appears to "compress" the weave
pattern to get closer to the trailing edge of the paper.  As a result,
I'd like to suggest the following.

I guess the weave normally starts printing with the bottom nozzle.
Assume we're advancing the paper by x each pass, the nozzle separation
is s, and assume that x > s.  We can instead start printing with the top
nozzle and advance the paper by (x - s) until the weave has expanded to
use all nozzles, then start advancing by x as before.

This could also be done in reverse at the bottom margin, as I've seen
the Windows ESC3000 driver do; at the moment, printing a full A4 page
with gimp-print results in the paper coming out from under the 870's push
rollers and being held only by those "trademark" Epson spiky metal wheels,
resulting in inaccurate paper positioning and a fuzzy bottom edge to
the print.  The 750/1200 programming guide talks about margin expansion
using "ESC ( S"; I think this is what is supposed to allow the paper to
feed that far, but it gives bad results because of the paper misalignment.
(In the 870's Windows driver, selecting "maximum printable area" instead
of "standard printable area" results in a little pop-up box warning:
"This setting allows you to extend the printable area, but print quality
may decline in the expanded areas.  Do not select this setting if you are
printing on Premium Glossy Photo Paper.")  If we could adjust the weave
pattern to give the same margins without advancing the paper so far,
it should improve print quality near the trailing edge of the page.

If the weave was started from the top nozzle as described, that might give
banding near the top of the print (as the comments above the softweave
code in print-escp2.c describe), so here's another idea: start the weave
from the middle of the print head, and feed by (x - s) alternately with x,
expanding the weave towards the bottom of the print head when feeding
by (x - s) and towards the top of the print head when feeding by x.
(And vice-versa and in reverse at the bottom margin, of course.)

(Of course, if it's possible to reverse-feed the paper before starting
to print at the top margin, it might not be necessary to do this weave
compression at the leading edge, but it would probably still be desirable
at the trailing edge of the paper.)

One other thing:  If I press the "Cancel" button during rendering,
the data that has already been piped into lpr gets printed anyway.
This should not happen.  However, I'm not sure how it should be fixed
short of writing to a temp file and then passing this to lpr later,
and that would be bad because a full A4 print can produce a spool file
of up to 90MB.  Perhaps gimp-print should send a signal to lpr to kill
it if the user hits "cancel"?

On Sat, May 06, 2000 at 08:16:55PM -0400, Robert L Krawitz wrote:
> Well, I hooked up the 870 today.  Here's the first things I noticed:
>=20
> 1) The standard Epson density (.6'ish) is all wrong for this printer.
>    I had to scale it to 1.3 (which really means 1.3 * .6, or about .8)
>    to get anything that looked even remotely reasonable.  Even that's
>    a bit too low (I'm using photo glossy paper).  I also had to knock
>    down both gamma and brightness a bit (.9 gamma and 80 brightness;
>    that gamma might be just a bit too low).  Ron van Ostayen suggested
>    a value of 1.6 for his ESC 900; that creates solid blacks, but it
>    definitely drops too much ink (see below).
>=20
>    This might explain why people with 900's are complaining that
>    output is too light.  Maybe all the variable dot size printers need
>    adjustment.

I think this depends on the source image really.  A friend asked for
four images to be printed today, and we used a brightness of about 75,
red=3Dblue=3Dgreen=3D100 and density=3D1.5.  For images from our camera, th=
at
seems to be too yellow, and the brightness doesn't need to be reduced...

> 2) The ink dries very slowly.

I didn't find this.  I used the ink that came with the printer, and Epson
A4 Photo Paper.  I haven't yet managed to smudge a print.  In fact,
I put one print through upside down to try a black and white print on
the back, and the print on the front seems unaffected.  I didn't manage
to smudge the printing on either side.

> 3) Pale tones are very good indeed.  Gray is very neutral.  However,

I agree.  The fountain fills I printed are very smooth.  Looking again,
the grey goes very slightly green between about 35% and 75% black.

> 4) Mid and dark tones are grainy.  It's less obvious when I push the
>    density up.  It might be a sign that the dither algorithm has
>    problems here; it might also simply be a sign that the density is
>    too low.  The grain looks a little bit like "shadowing" from large
>    dots, but not entirely.

I'm not sure I've seen this.  Very dark areas occasionally "black out",
but gimp-print does this far less than the Windows driver does when
printing to our ESC3000.

> 6) The printer is nearly silent -- a nice change after the noisy EX.

Nice, isn't it?  I'm not sure about the way it "tweets" when it's
turned on.  ;)

> 7) I think the high density results in too much ink being dropped

Hmm...  I appear to have already used up half a colour cartridge.
The black cartridge is nearly full, though.  I suppose black carts have
far more black ink in them than the colour carts have of each colour.

> 8) Printing multiple images on the same page by means of multiple
>    print runs is troublesome.  Think slow-drying ink.  Also, even
>    after having dried for over 5 hours, the rollers still managed to
>    pick some ink off the paper.  This is less than thrilling from a
>    development standpoint; I like to print very small images 25 to a
>    page.

I do something very similar, but have had no problems with the ink.
The little metal rollers do make dents in the paper, and the cumulative
effect is kind of ugly after the paper has been through the printer a
dozen times.  I haven't had problems with ink coming off, though.


Well, I've probably bored you for long enough now.  Thanks for reading
this far.  ;)

And thanks for all the work you (all) have already done on gimp-print!
I mentioned above that a friend (a newspaper photographer) had asked
for some images printed.  He has a Photo 700 (and no ink at present) and
uses Windows (NT I think).  After seeing the prints gimp-print produced,
he said he wanted a new printer.  Congratulations!

Cheers,

--=20
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

Re: [Gimp-print-devel] ESP 750 MODEL_INIT

[Karl H. K. <kh...@kh...>]

On Mon, May 08, 2000 at 08:15:59AM -0400, Robert L Krawitz wrote:
>    It's _NOT_ necessary for the stc740. That's all I know. I think that e=
very
>    printer _AFTER_ the 740 needs this string.=3D20
>=20
> Well, there you go.  I think the 900 is a later generation than the
> 740, even though they're both listed as 99a printers.  I suspect the
> 870 is going to be the same as the 900 in this regard.

The 870 requires the same init string, I have confirmed this (and
I think the 800 was the one mentioned on the USB list).

>=20
>    > Maybe I should get a USB cable.  I think kernel 2.2.15 supports USB
>    > printers.  It would let me test both USB connectivity and have both
>    > printers hooked up at once.  Although where I'll put the other print=
er
>    > is beyond me.
>=20
>    I have three printers and two scanners connected to my computer :-)
>=20
> All USB?

Two printers and one scanner are USB, one printer is parallel and
one scanner is SCSI (and I forgot to mention my old NEC inkjet
that has no space on my desk anymore and has also a parallel=20
interface). The one thing I have not yet managed to do is to
randomly connect one or both of the USB printers and get it to
be assigned to the same usb special device every time... This
is a limitation of the current (OK I have to admit 2.3.39 is
not really current, but this backport was the only one that
worked with my scanner) USB implementation.=20

Karl Heinz

--=20
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net

Re: [Gimp-print-devel] Ghost script versions

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

   From: sh...@al...
   Date: Mon, 08 May 2000 08:27:04 -0400

   The README file in the Ghost directory says to use gs 5.50 or later.
   Is there any known incompatibility with gs 5.10?

Nothing I specifically know of; 5.50 is the version I happen to have
at hand.

[Gimp-print-devel] Ghost script versions

[<sh...@al...>]

The README file in the Ghost directory says to use gs 5.50 or later.
Is there any known incompatibility with gs 5.10?

Eric

[Gimp-print-devel] Re: Light inks (was: HP deskjet 690c)

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

   Date: Mon, 08 May 2000 12:27:20 +0100
   From: Dave Hill <da...@mi...>

   where the values are the density of the light ink compared to the
   ordinary one. What happens if you specify a "light ink density" and
   then don't supply a buffer to dither_cmyk(), I don't know!

You'll get a bus error or a seg fault when the dither code tries to
write to the nonexistent light buffer.  That's why the out of
specifying a zero light ink density; that turns off light ink printing
for that color.

   Robert, does this make sense or am I writing drivel? How do you work
   out the values of the dither knobs? Do you print colour gradients and
   look at the transitions?

It makes more sense than anything I've written about it (because I
haven't gotten off my duff and documented this yet).  As far working
out the transitions -- that's precisely what I do.

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

Re: [Gimp-print-devel] ESP 750 MODEL_INIT

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

   Date: Mon, 8 May 2000 06:11:52 -0400
   From: Karl Heinz Kremer <kh...@kh...>

   On Sun, May 07, 2000 at 10:28:16PM -0400, Robert L Krawitz wrote:

   > I think that what happened is that someone complained about this
   > problem on a 900, and nobody said anything else about it on any other
   > model.  Should this be set on all third generation
   > (440/640/740/900/750/1200) printers and beyond?  My 870 is hooked up
   > to my parallel port, so I can't test it.

   It's _NOT_ necessary for the stc740. That's all I know. I think that every
   printer _AFTER_ the 740 needs this string.=20

Well, there you go.  I think the 900 is a later generation than the
740, even though they're both listed as 99a printers.  I suspect the
870 is going to be the same as the 900 in this regard.

   > Maybe I should get a USB cable.  I think kernel 2.2.15 supports USB
   > printers.  It would let me test both USB connectivity and have both
   > printers hooked up at once.  Although where I'll put the other printer
   > is beyond me.

   I have three printers and two scanners connected to my computer :-)

All USB?

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

Re: [Gimp-print-devel] Canon driver

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

   Date: Mon, 08 May 2000 09:01:03 +0200
   From: Andy Thaller <th...@ph...>

   I've tested the canon driver's output this weekend, though not with
   every dither algorithm. 360x360 and 720x720 dpi seem fine, though
   slighty mistuned in respect to brightnes and contrast. 360x360 with
   variable dot sizes shows extreme color corruption (what can I do
   here?) and 1440x720 is way too dark.

1) For 1440x720, you need to divide v->density by 2.  Apparently the
Canon printers are like the Epson printers in this regard -- they're
really 720x720, and 1440 is done in two passes.

2) You probably want to fiddle with the_levels.

  double        the_levels[] = { 0.5, 0.75, 1.0 };

This indicates that there are three dot sizes, of size .5, .75, and
1.0 respectively.  However, I doubt that those being a bit off would
cause even moderately severe color corruption.  Most likely the format
of the output is wrong.  The dither routine normally generates the
output as concatenated rows, with the lowest bit plane first.  It's
possible (by means of dither_set_c_ranges and such) to change that
ordering around.  If Canon takes each pixel as a full unit, you need a
folding routine like that in print-escp2.c

   Given my current schedule I won't have much time within the next
   two months to fiddle around with the settings. So Robert, since I
   seem to be the only canon-user on this list (tell me if I'm wrong)
   we should consider to post some kind of job-announcement on
   sourceforge? At least you mentioned the possibility somewhere.

I'm not aware of any other Canon users.  Want me to post a job
announcement?

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

Re: [Gimp-print-devel] HP deskjet 690c

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

   Date: Mon, 8 May 2000 07:51:49 +0200 (CEST)
   From: Henk Verleye <he...@so...>

   On Fri, 5 May 2000, Dave Hill wrote:

   > I don't know the values for the HP inks, so I just used the same
   > as the Epson ones (0.25, 0.25, 0).

   Could you explain what this means? If I know how to determine those
   values, I may be able to provide them.

They're the ratios between the darkness of light and dark cyan,
magenta, and yellow inks respectively.  A ratio of zero indicates that
this ink does not have a light variant.

This is the call used for simple single-level inks (one dot size).
For variable dot size, the calls are different.

Re: [Gimp-print-devel] HP deskjet 690c

[Dave H. <da...@mi...>]

Henk Verleye wrote:
> 
> On Fri, 5 May 2000, Dave Hill wrote:
> 
> > I don't know the values for the HP inks, so I just used the same
> > as the Epson ones (0.25, 0.25, 0).
> 
> Could you explain what this means? If I know how to determine those
> values, I may be able to provide them.
> 

As far as I can tell, it is the density factor for the light inks
(i.e. Light Cyan is 0.25 times as dense as Cyan ...). There is
no "light yellow", so the third one is zero.

Dave


-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
				davehill at users.sourceforge.net
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

[Gimp-print-devel] Re: Light inks (was: HP deskjet 690c)

[Dave H. <da...@mi...>]

Andy Thaller wrote:
> 
> Well, actually it's some time since I've done any work on the canon
> driver and I still can't test 6 color printing lacking the appropriate
> ink :-/
> So what exaclty did you do to make it work or would you mind adding it
> to the canon driver also?
> 
> Andy.
> 

It seems that in the olden days (before the last round of major
dither changes), the values of "light" inks were pre-set in
init_dither (variables lc_level etc). In print-dither 1.19, for
example, the values are (24576/65536) = 0.37.

However, now, it seems that in order to get "light" ink output,
you have to explicitly tell the dither code to do it.

What I did was this:-

If you are *not* using 4-level dithers (i.e. in the canon case
you are not "using_dmt"):-

dither_set_light_inks(dither, light_cyan_density, light_magenta_density,
light_yellow_density, v->density);

where the values are the density of the light ink compared to the
ordinary one. What happens if you specify a "light ink density" and
then don't supply a buffer to dither_cmyk(), I don't know!

If you are using DMT, then it seems to become more complicated.
Instead of calling dither_set_c_ranges_simple(), for each colour
that has a light ink, you have to call dither_set_c_ranges() instead.
This takes an array that seems to map the "equivalent dot size"? to
the dither output ('01', '10' or '11') and which ink to use (0=light,
1=dark).

I fathomed all this out by looking in the source of print-escp2.c.
Whether I could put it into print-canon without breaking it is
another matter!

Robert, does this make sense or am I writing drivel? How do you work
out the values of the dither knobs? Do you print colour gradients and
look at the transitions?

Dave

-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
				davehill at users.sourceforge.net
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

[khk@khk.net: Re: [Gimp-print-devel] ESP 750 MODEL_INIT]

[Karl H. K. <kh...@kh...>]

=2E.. wrong key ...
----- Forwarded message from Karl Heinz Kremer <kh...@kh...> -----

Date: Mon, 8 May 2000 06:11:52 -0400
From: Karl Heinz Kremer <kh...@kh...>
To: Robert L Krawitz <rl...@al...>
Subject: Re: [Gimp-print-devel] ESP 750 MODEL_INIT
X-Mailer: Mutt 1.0i

On Sun, May 07, 2000 at 10:28:16PM -0400, Robert L Krawitz wrote:
>    From: sh...@al...
>    Date: Sun, 07 May 2000 20:47:03 -0400
>=20
>    Can someone remind me, was there a reason the ESP 750 is MODEL_INIT_ST=
ANDARD
>    rather than MODEL_INIT_900.  Were there bug reports of problems as _90=
0?
>=20
> I think that what happened is that someone complained about this
> problem on a 900, and nobody said anything else about it on any other
> model.  Should this be set on all third generation
> (440/640/740/900/750/1200) printers and beyond?  My 870 is hooked up
> to my parallel port, so I can't test it.

It's _NOT_ necessary for the stc740. That's all I know. I think that every
printer _AFTER_ the 740 needs this string.=20

>=20
> Maybe I should get a USB cable.  I think kernel 2.2.15 supports USB
> printers.  It would let me test both USB connectivity and have both
> printers hooked up at once.  Although where I'll put the other printer
> is beyond me.

I have three printers and two scanners connected to my computer :-)

Karl Heinz


--=20
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net



----- End forwarded message -----

--=20
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net

Re: [Gimp-print-devel] ESP 750 MODEL_INIT

[Karl H. K. <kh...@kh...>]

On Sun, May 07, 2000 at 10:24:47PM -0400, Robert L Krawitz wrote:
>=20
>    And why would you want two different queues going to the same printer?

Because I can :-)

>=20
> As a really ugly hack, to have two computers share one printer without
> setting up a proper lpd configuration.  No, I don't want to think
> about the implications of this.  It's too ugly.

There was some discussion about this on the USB list. I don't want to=20
do this myself, but I think there is one semi-valid reason: If you=20
have a computer that you don't want to network because of security
reasons, but you still want to be able to print.=20


--=20
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net

[Gimp-print-devel] Canon driver

[Andy T. <th...@ph...>]

Hi,

I've tested the canon driver's output this weekend, though not with every
dither algorithm. 360x360 and 720x720 dpi seem fine, though slighty mistuned
in respect to brightnes and contrast. 360x360 with variable dot sizes shows
extreme color corruption (what can I do here?) and 1440x720 is way too dark.

Given my current schedule I won't have much time within the next two months to
fiddle around with the settings. So Robert, since I seem to be the only
canon-user on this list (tell me if I'm wrong) we should consider to post some
kind of job-announcement on sourceforge? At least you mentioned the
possibility somewhere.

Andy.

--
Andy Thaller
TU Muenchen, Physikdepartment E11       Tel: ++49 (0)89 289 12860
James Franck Str.                       Fax: ++49 (0)89 289 12842
85748 Garching   //  Germany            email:  th...@ph...

Re: [Gimp-print-devel] HP deskjet 690c

[Henk V. <he...@so...>]

On Fri, 5 May 2000, Dave Hill wrote:

> I don't know the values for the HP inks, so I just used the same
> as the Epson ones (0.25, 0.25, 0).

Could you explain what this means? If I know how to determine those
values, I may be able to provide them.

Henk Verleye

Re: [Gimp-print-devel] HP deskjet 690c

[Andy T. <th...@ph...>]

Dave Hill wrote:

> Hi
>
> I have just submitted the 6 colour printing stuff. It seems to
> do the right thing but may need tweaking.
>
> To use it, select "DJ690", then select "Color + Photo" from the
> ink type selection.
>
> One interesting thing that I found is that in order to get output
> into the "light cyan" and "light magenta" buffers, I had to call
> dither_set_light_inks(). But the canon driver doesn't do this -
> does this mean it isn't actually doing light inks at all?
>
> I don't know the values for the HP inks, so I just used the same
> as the Epson ones (0.25, 0.25, 0).

Well, actually it's some time since I've done any work on the canon driver and
I still can't test 6 color printing lacking the appropriate ink :-/
So what exaclty did you do to make it work or would you mind adding it to the
canon driver also?

Andy.

--
Andy Thaller
TU Muenchen, Physikdepartment E11       Tel: ++49 (0)89 289 12860
James Franck Str.                       Fax: ++49 (0)89 289 12842
85748 Garching   //  Germany            email:  th...@ph...

Re: [Gimp-print-devel] ESP 750 MODEL_INIT

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

   From: sh...@al...
   Date: Sun, 07 May 2000 20:47:03 -0400

   Can someone remind me, was there a reason the ESP 750 is MODEL_INIT_STANDARD
   rather than MODEL_INIT_900.  Were there bug reports of problems as _900?

I think that what happened is that someone complained about this
problem on a 900, and nobody said anything else about it on any other
model.  Should this be set on all third generation
(440/640/740/900/750/1200) printers and beyond?  My 870 is hooked up
to my parallel port, so I can't test it.

Maybe I should get a USB cable.  I think kernel 2.2.15 supports USB
printers.  It would let me test both USB connectivity and have both
printers hooked up at once.  Although where I'll put the other printer
is beyond me.

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

Re: [Gimp-print-devel] ESP 750 MODEL_INIT

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

   From: sh...@al...
   Date: Sun, 07 May 2000 21:32:04 -0400

   Since this string does appear in the Windows driver ouptut, it seems
   that the Epson engineers felt the need to include it in every print
   job rather than having it sent as Windows configures its USB devices
   at boot/insertion.  They apparently didn't think it was such a bad thing
   to do.  I'm inclined to agree.  It's just a few bytes and it guarentees
   that the device will work.  I don't know why the printer has the behavior
   of not listening to jobs from the USB port without that string anyway.

Well, there's no real harm in taking the belt and suspenders
approach.  I agree that sending this string with the print job is
somewhat lame, but it's also safe, and doesn't require the user to
know about this hack.  The more stuff the user has to configure, the
more likely that things will go wrong.  Sending the init string with
the print job is apparently foolproof.

   And why would you want two different queues going to the same printer?

As a really ugly hack, to have two computers share one printer without
setting up a proper lpd configuration.  No, I don't want to think
about the implications of this.  It's too ugly.

Re: [Gimp-print-devel] ESP 750 MODEL_INIT

[<sh...@al...>]

>   - Use the usbd daemon to send "firmware" to the device. That's what it's
>     supposed to be used for, it can sense a new device and can take the
>     necessary steps to initialize it. In our case it could just send the
>     init string to the printer.

This is the better way to do it, given those two options, but I'm not
certain that I agree with you.  (Setting an input filter is even more of a
cheesy hack than putting this code in the printer driver, IMO.)

Since this string does appear in the Windows driver ouptut, it seems
that the Epson engineers felt the need to include it in every print
job rather than having it sent as Windows configures its USB devices
at boot/insertion.  They apparently didn't think it was such a bad thing
to do.  I'm inclined to agree.  It's just a few bytes and it guarentees
that the device will work.  I don't know why the printer has the behavior
of not listening to jobs from the USB port without that string anyway.

And why would you want two different queues going to the same printer?

Eric

Re: [Gimp-print-devel] ESP 750 MODEL_INIT

[Karl H. K. <kh...@kh...>]

On Sun, May 07, 2000 at 08:47:03PM -0400, sh...@al... wrote:
> 
> Can someone remind me, was there a reason the ESP 750 is MODEL_INIT_STANDARD
> rather than MODEL_INIT_900.  Were there bug reports of problems as _900?
> 
> I seem to have a vague recollection of something like this, but my brain
> seems to be accessing corrupted memory.  To much exposure to that great
> big burning hydrogen ball today.  Anybody else ever see that? ;)
> 
> It seems to work ok for me as _900, and it won't work without it over USB.

It looks like every USB printer after the stc740 requires some special
init sequence to "connect" the interpreter with the USB port. By default
it only accepts jobs from the parallel port. In my opinion it should not
be the print plugin's responsibility to do this. In theory you just can
send this string once per session - the printer will continue to accept
jobs via the USB I/F until you power it down. I can see two ways of
doing this outside the print plugin:

  - Use the usbd daemon to send "firmware" to the device. That's what it's
    supposed to be used for, it can sense a new device and can take the
    necessary steps to initialize it. In our case it could just send the
    init string to the printer.

  - Use an input filter in /etc/printcap to always send the init string before
    the actual print job. This has the advantage that you can connect two 
    different queues to the same printer: Once via the parallel port and the
    second one via the USB port.

My /etc/printcap contains the following line:
[...]
       :if=/var/spool/lpd/epson-usb/epson-filter:\   
[...]

The epson-filter contains the following:

#!/bin/bash
exec cat /var/spool/lpd/epson-usb/epson-usb-codes - 

... and the file epson-usb-code is attached to this mail. 

Hope this helps,

Karl Heinz

-- 
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net

[Gimp-print-devel] ESP 750 MODEL_INIT

[<sh...@al...>]

Can someone remind me, was there a reason the ESP 750 is MODEL_INIT_STANDARD
rather than MODEL_INIT_900.  Were there bug reports of problems as _900?

I seem to have a vague recollection of something like this, but my brain
seems to be accessing corrupted memory.  To much exposure to that great
big burning hydrogen ball today.  Anybody else ever see that? ;)

It seems to work ok for me as _900, and it won't work without it over USB.

Eric