gimp-print-devel

[Gimp-print-devel] Hybrid Floyd-Steinberg, again

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

Well, I just found a major, if trivial, bug in hybrid Floyd-Steinberg
that accounts for all of the ugliness in that mode (specifically, a
missing break in a case statement).  It looks vastly better now (both
the adaptive and the pure hybrid variants).  I strongly urge everyone
to give it another try.

-- 
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] Compilation error (was: Andy or Mitch, please read the Help forum)

[S. M. <sm...@rn...>]

Robert L Krawitz wrote:
> 
> Try running ldconfig after installing the Gimp.  Unfortunately, that
> doesn't happen automatically...

Sven, Karl, and Robert:
ldconfig fixed it - thanks for everyone's input.  A quick test on last
night's repository with my stc740: The image I used is a small tiff of
Rasputin - pale face with deep shadows, wearing a long dark grey coat. 
It provides good test of fleshtones and contrast. The random FS (at 360
and 720 microweave) left some very odd orangish hilights.  Adaptive
hybrid looked pretty good, but showed some dark speckles (patterned) in
a light colored facial area.  I accidently overprinted this on the 760
microweave fs, and the result was surprisingly good, if a tad saturated
:)  As I get time I will try more variations, but would prefer to devote
more time to the gui.

I hope to get the notebook gui out within the next week or two.  I
apologize for the slowness - I recently started a new job and have been
working longer hours, leaving very little free time.

Steve
-- 
-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------

Re: [Gimp-print-devel] Stylus photo 870

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

   Date: Fri, 5 May 2000 23:51:30 +0000
   From: Jean-Marc Verbavatz <ver...@if...>

   > Huh.  That's very interesting, and doesn't accord with my experience.
   > I would expect stock 3.1.3 to be the least grainy, followed by the
   > current repository and then 3.1.2.  3.1.2 might be denser, which would
   > reduce the perceived grain.

   Right, this is not what I meant. Saying that the current repository
   was lousy was an overstatement. I meant it's too dark to tell. For
   3.1.2 I meant a version that I had modified. I would otherwise
   agree with you.

The current repository prints too dark?  I thought I reduced the
density.

   I think the density ratio between colors is simply not one. I'll
   send you a patch over the week end, that mostly fixes grays. To get
   it absolutely right, we need to address the grain issue first
   though. To fix red and blue, the only thing I came up with were hue
   adjustements.

I think you're probably correct.  See my next message, though, about
grain.

   > I think that the black threshold is a bit too low right now.

   Yes indeed. The new k_lower in print-escp2 .138, looks better already. That
   does not totally fix the problem, but helps very much.

We can always tweak it a bit more.

   Well this does not improve things in my opinion. It is lighter as
   you would expect, but grain remains. The change in k_lower is much
   more useful.

OK, we won't go down that path.

   Have you tried to print a black and white picture in color mode ?
   I've noticed that, beyond the greenish tone, it shows diffuse
   magenta grains, particularly around transitions and I could not
   figure out why. Interestingly, I've noticed that (now that black is
   better), grain in color pictures was mostly magenta as well and in
   fact localized in exactly the same regions. Is it just me ?

You know, I've seen some oddities with (not so diffuse) magenta in
some things at extremely low densities.  At this point, I don't know
if it's due to the image or if magenta alone is somehow being handled
incorrectly.

-- 
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] EPSON Stylus 840

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

   Date: Fri, 05 May 2000 17:15:46 -0500
   From: Chema Celorio <che...@ce...>

   Let me introduce myself. I am Chema Celorio. I live
   in Mexico City and I have been working with GNOME,
   specially with gnome-print. I have been working
   with gnome-print's PCL native driver.

Hi!

   I compiled gimp-print today ( CVS version )
   to test it with my Epson Sylus 860.
   Here are the results in the diferent modes.
   The type was set to "photograph".

   360 BW  - ok
   720 Microweave - ok
   720 Softweave - problem #1
   720 High Quality - problem #1
   1440 720 Micro - problem #2
   1440 720 soft - problem #1
   1440 720 enhnaced - problem #1

   Problem #1
   -
   After the job is sent to the printer, the printer
   starts ejecting blank sheets, one after another.
   I have to reset the printer 2 or 3 times to flush
   the data.

That indicates that the support for the 860 isn't correct yet.  It's a
new printer, and I only just got doc (which unfortunately I can't
share yet) on it.  I can't promise when it will be working.

   Problem #2
   -
   A page came out, but between each row of pixels there is
   like a 1/4 centimeter separation of the image.

Hmm.

Re: [Gimp-print-devel] Autoconfig trouble...

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

You need to install gimp.m4 from your Gimp installation into your
aclocal directory (probably /usr/share/aclocal or
/usr/local/share/aclocal).  I thought the Gimp did that (when
installed as root, at any rate), but maybe not.

If you do run aclocal, beware that versions of the Gimp from 1.1.17
and earlier have a version of gimp.m4 that will create an incorrect
configure script.  The patch is as follows:

diff -u /usr/local/share/aclocal/gimp.m4~ /usr/local/share/aclocal/gimp.m4
--- /usr/local/share/aclocal/gimp.m4~   Tue Mar 30 13:49:58 1999
+++ /usr/local/share/aclocal/gimp.m4    Fri Feb 11 22:34:47 2000
@@ -134,6 +134,13 @@
           AC_TRY_LINK([
 #include <stdio.h>
 #include <libgimp/gimp.h>
+GPlugInInfo    PLUG_IN_INFO =          /* Plug-in information */
+{
+  NULL,    /* init_proc */
+  NULL,    /* quit_proc */
+  NULL,   /* query_proc */
+  NULL,     /* run_proc */
+};
 ],      [ return 0; ],
         [ echo "*** The test program compiled, but did not run. This usually means"
           echo "*** that the run-time linker is not finding GIMP or finding the wrong"

Re: [Gimp-print-devel] Stylus photo 870

[Jean-Marc V. <ver...@if...>]

>    I just printed the exact same photograph (a rather difficult one
>    from previous experience) with my version of gimp-print-3.1.2 (a),
>    with stock 3.1.3 (b), yesterday's 3.1.3 with dither=2 (c) and with
>    dither=4 (d).  b, compared to others is lousy. That's history.  c
>    and d don't differ significantly. They're good. A bit grainy,
>    slightly oversaturated, greenish grays (see above).  At this point
>    (a) is best in my opinion. A little less saturated than c,d (but
>    whether this is worse or better is rather subjective and can be
>    adjusted).  Better grays. Less grainy.
>
> Huh.  That's very interesting, and doesn't accord with my experience.
> I would expect stock 3.1.3 to be the least grainy, followed by the
> current repository and then 3.1.2.  3.1.2 might be denser, which would
> reduce the perceived grain.
>
Right, this is not what I meant. Saying that the current repository was lousy
was an overstatement. I meant it's too dark to tell. For 3.1.2 I meant a
version that I had modified. I would otherwise agree with you.


>    The greenish thing should not be difficult to fix. That's color
>    balance again and probably involves no specific flow in the
>    algorithms.
>
> I hope not, but it's been exceedingly difficult to get right thus far.

I think the density ratio between colors is simply not one. I'll send you a
patch over the week end, that mostly fixes grays. To get it absolutely right,
we need to address the grain issue first though. To fix red and blue, the only
thing I came up with were hue adjustements.

>
> Actually, gray IS printed as CMY (and LC and LM as appropriate) until
> it gets quite dark.  And currently, there's some CMY mixed in all the
> way to almost 100% black.
>
I know and I can't argue with that until I understand the new dithering a
little better. This was just a general thought.

>
> I think that the black threshold is a bit too low right now.

Yes indeed. The new k_lower in print-escp2 .138, looks better already. That
does not totally fix the problem, but helps very much.

> It's
> also possible that the density value that's being used to compute the
> size of the black dot is wrong.  Try changing this:
>
> 	  tk = print_color(d, &(d->k_dither), bk, bk, k, x, row, kptr,
> 			   NULL, bit, length, 0, 0, 0, 0);
>
> to
>
> 	  tk = print_color(d, &(d->k_dither), bk, bk - d->k_lower, k, x, row,
kptr,
> 			   NULL, bit, length, 0, 0, 0, 0);
>
> What this will do is decide what kind of black dot to print based on
> the difference between the black value and the lowest value at which
> black is printed, rather than the absolute black value.  So that would
> use smaller dots.  Let me know how it works.
>
Well this does not improve things in my opinion. It is lighter as you would
expect, but grain remains. The change in k_lower is much more useful.

Have you tried to print a black and white picture in color mode ? I've noticed
that, beyond the greenish tone, it shows diffuse magenta grains, particularly
around transitions and I could not figure out why. Interestingly, I've noticed
that (now that black is better), grain in color pictures was mostly magenta as
well and in fact localized in exactly the same regions. Is it just me ?



-- 
--
Jean-Marc Verbavatz		<ver...@if...>
5, rue La Fontaine		"http://perso.cybercable.fr/verbavat"
F-75016 Paris

[Gimp-print-devel] CORRECTION : EPSON Stylus 860 <-- NOT 840

[Chema C. <ch...@ce...>]

there was a typo in the title to my last message.
the printer model is Epson Sylus 860 not 840.

Chema

[Gimp-print-devel] EPSON Stylus 840

[Chema C. <che...@ce...>]

Hi gimp-printer's

Let me introduce myself. I am Chema Celorio. I live
in Mexico City and I have been working with GNOME,
specially with gnome-print. I have been working
with gnome-print's PCL native driver.

I compiled gimp-print today ( CVS version )
to test it with my Epson Sylus 860.
Here are the results in the diferent modes.
The type was set to "photograph".

360 BW  - ok
720 Microweave - ok
720 Softweave - problem #1
720 High Quality - problem #1
1440 720 Micro - problem #2
1440 720 soft - problem #1
1440 720 enhnaced - problem #1

Problem #1
-
After the job is sent to the printer, the printer
starts ejecting blank sheets, one after another.
I have to reset the printer 2 or 3 times to flush
the data.

Problem #2
-
A page came out, but between each row of pixels there is
like a 1/4 centimeter separation of the image.

Chema

[Gimp-print-devel] Autoconfig trouble...

[Audin M. <am...@ha...>]

	I'm trying to build gimp-print for the first time here...and i'm
having problems with autoconfig...

	I do this:

[amalmin@skaro print]$ pwd
/home/amalmin/src/gimp-print/print
[amalmin@skaro print]$ autoconf  
[amalmin@skaro print]$ ./configure 
loading cache ./config.cache
./configure: syntax error near unexpected token `AM_INIT_AUTOMAKE(print,3.1.4)'
./configure: ./configure: line 521: `AM_INIT_AUTOMAKE(print,3.1.4)'

	So, looking at the mailing list archives, I'm told to do this first:

[amalmin@skaro print]$ aclocal 
aclocal: configure.in: 43: macro `AM_PATH_GIMP' not found in library

	But that still doesn't work...AM_PATH_GIMP is called in configure.in...
but doesn't seem to be defined anywhere else...

	My gimp is:

[amalmin@skaro print]$ gimp -v
GIMP version 1.1.17

	Built from source...on what was once long ago a Redhat 5.1 setup...

-- 
                                            Audin Malmin - am...@ha...

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

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

Pållen wrote:
> 
> On Thu, 4 May 2000, Henk Verleye wrote:
> 
> > In the supported printer list for the gimp-print project, the HP DeskJet
> > 600 series is there.  Does this also include the 690 series (= a 6 ink
> 
> the 815C doesn't seem to be included in the 800 series at least.
> 
> I can't get anything usefull out of it at least. The 600 driver works
> "good".
> 
> (Okay, this could be a very old version of gimp)
> 

The 800 series support was broken, I have just checked in a fix,
please try it again!

Dave Hill

-- 
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] HP deskjet 690c

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

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

Dave Hill

PS I also fixed the 800 series support that rlk broke on 04/18
(when he swapped the calls to writefunc, he didn't transfer the
"last plane" argument to the last one!).

-- 
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] small problem with gimp 1.0 vs 1.1(.21)

[Michael N. <mit...@cs...>]

Andy Thaller wrote:
> 
> The part in print_gimp.h
> 
> #if !defined(GIMP_MINOR_VERSION) || (GIMP_MAJOR_VERSION == 1 &&
> GIMP_MINOR_VERSION == 0) || (GIMP_MAJOR_VERSION == 1 && GIMP_MINOR_VERSION ==
> 1 && GIMP_MICRO_VERSION < 21)
> #define GIMP_1_0
> #endif
> 
> unhibits saving of the printrc file for any version of gimp-1.1 but 1.1.21
> because it tried to save to ~/.gimp/printrc
> probaply we should have a GIMP_1_0, GIMP_1_1 and GIMP_1_2 or something like
> that?

Andy,

I've just commited a patch which checks for (GIMP_MINOR_VERSION == 0)
instead of GIMP_1_0 in this case. Should work now for all Gimp versions.

bye,
--Mitch

[Gimp-print-devel] small problem with gimp 1.0 vs 1.1(.21)

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

The part in print_gimp.h

#if !defined(GIMP_MINOR_VERSION) || (GIMP_MAJOR_VERSION == 1 &&
GIMP_MINOR_VERSION == 0) || (GIMP_MAJOR_VERSION == 1 && GIMP_MINOR_VERSION ==
1 && GIMP_MICRO_VERSION < 21)
#define GIMP_1_0
#endif

unhibits saving of the printrc file for any version of gimp-1.1 but 1.1.21
because it tried to save to ~/.gimp/printrc
probaply we should have a GIMP_1_0, GIMP_1_1 and GIMP_1_2 or something like
that?

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

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

Henk Verleye wrote:
> 

[snip explanation]

Thanks, that's just the confirmation I needed.

I'll get coding!

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] More stuff

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

   Date: Fri, 05 May 2000 11:01:11 +0200
   From: Ron van Ostayen <R.A...@Wb...>

   Robert L Krawitz wrote:
   > 
   >    Date: Thu, 04 May 2000 12:57:49 +0200
   >    From: Ron van Ostayen <R.A...@Wb...>
   > 
   >    Quality   Time(s)  FileSize     Printing time (time cat tiger0..9.prn >
   >    /dev/lp0)
   >      0        33.2     1986522       18.5  OK but top margin is approx
   >    0.9cm smaller than for other settings.
   >      1       112.1     7118815       68.0  OK
   >      2       110.6     7118808       error in output (empty pages and
   >    garbage)
   >      3       116.1         955 !!
   >      4      signal 11
   >      5       191.5     9977020      121.0  OK
   >      6       190.2         605 !!
   >      7       198.7        2042 !!
   >      8       356.4        2127 !!
   >      9       390.9        1549 !!
   > 
   >    I have succesfully tested 3.1.3 with quality setting 0,1,2,3,5,6 and 8
   >    so the last changes seem to have broken some settings.
   > 
   > Could you retest settings 2, 3, and 6?

   I have, and they are still broken.  The output file sizes are not
   exactly the same, but mode 2 still produces blank and garbage pages, and
   modes 3 and 6 produce small files.

I could not find any material difference between the output in 3.1.3
and the repository (at least while using the print plugin -- I haven't
had time to try the Ghostscript driver).  There was a minor mistake in
softweave mode (ink drop size wasn't set if the correct size for that
printer is zero), but that was the case in both versions.  I've fixed
it, so you might as well give it a shot.

Could you do me a favor?  You'll find a perl script named parse-escp2
in the repository.  Please run that over the output from mode 2 and
mode 3, and send me about the first 30 lines of output (the output
from mode 2 might be fairly voluminous).

-- 
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] More stuff

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

   Date: Fri, 05 May 2000 11:01:11 +0200
   From: Ron van Ostayen <R.A...@Wb...>

   I have, and they are still broken.  The output file sizes are not
   exactly the same, but mode 2 still produces blank and garbage pages, and
   modes 3 and 6 produce small files.

grr...

   > BTW, were you using ordered dither (dither=1)?  I think that might
   > account for the file size of 3, 6, 7, 8, and 9.  That bug should be
   > fixed.  Try dither=2 (random Floyd-Steinberg) and dither=4 (adaptive
   > random Floyd-Steinberg).

   I have used the default dither (dither=0?).
   Dither=2 doesn't change the result.

Does it change the appearance in any way when things do print correctly?

Re: [Gimp-print-devel] More stuff

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

   Date: Fri, 05 May 2000 10:56:06 +0200
   From: Ron van Ostayen <R.A...@Wb...>

   Robert L Krawitz wrote:

   The latest version I got from the repository has a value of 0.999.
   And yes, this works!!  Black images and text are printed in one
   pass like with the windows driver.

   I assume this will improve other resolution printout as well?

It did the right thing in my tests.

   > I know.  I've partially optimized it, but not completely.  That
   > shouldn't be all that hard to get right.  It's possible that what
   > looks empty isn't entirely, but it's possible to figure that out from
   > the print file, if what I eventually do to fix it doesn't solve the
   > problem.

   This seems to have been fixed also.
   So it would seem that the 360dpi mode achieves the same printing speed
   as the windows driver.
   Now all that remains is to improve the dithering speed :-).

It turned out to be very easy to get it right for microweave.  For
softweave, when I stared at it, it was trivial.  As for the dithering
speed, I need to profile it again some time and take a closer look at
what's going on.

   >    The quality of in particular the windows text is much better than the
   >    gimp-print output.  Figures and photos are comparable.
   > 
   > What's the difference (more specifically)?

   Well, I have studied a scan of the output and actually the
   difference isn't that bad.  It's just that the windows driver uses
   more ink.  More black, more color.  Which settings should I change
   to get this result?

For now, try bumping up the density to 1.1 or 1.2 and see if that
helps.  It may be that the current density setting is slightly too
low, or that we should have a separate density setting for black ink.
If 1.1 is good enough, try 1.05.  I want to cut this fairly close.
1.1 put noticeably too much ink on my paper.

-- 
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] Compilation error (was: Andy or Mitch, please read the Help forum)

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

   Date: Thu, 04 May 2000 19:58:25 -0700
   From: "S. Miller" <sm...@rn...>

   I've been having problems getting the repository to compile for about a
   week or so.  I finally got gimp 1.1.21 downloaded and compiled (a story
   all by itself), but have still been unsuccessful.  I get the following
   error:
   checking for GIMP - version >= 1.0.0... no
   *** Could not run GIMP test program, checking why...
   *** The test program failed to compile or link. See the file config.log
   for the
   *** exact error that occured. This usually means GIMP was incorrectly
   installed
   *** or that you have moved GIMP since it was installed. In the latter
   case, you
   *** may want to edit the gimptool script: /usr/local/bin/gimptool
   configure: error: Cannot find GIMP libs: Please run ldconfig
   make: *** [config.status] Error 1
   print> 

   As far as I can tell, the libs are where they've always been, and
   gimptool --version returns version 1.1.21.  My sandbox still compiles
   fine with an older version of configure.  As I'm getting fairly close to
   getting the notebook GUI done I'd like to make sure I can get everything
   to compile from the repository.  Any help would be appreciated.

Try running ldconfig after installing the Gimp.  Unfortunately, that
doesn't happen automatically...

Re: [Gimp-print-devel] Compilation error (was: Andy or Mitch, please read the Help forum)

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

On Thu, May 04, 2000 at 07:58:25PM -0700, S. Miller wrote:
> Michael Natterer wrote:
> >=20
> > I have restricted the test to Gimp 1.1.16 or better so the current
> > cvs version should build for everybody.
> >=20
> > Robert, I will add the code which requires Gimp 1.1.21 tonight (just
> > in case you plan to make a release to day).
> >=20
> > bye,
> > --Mitch
> >=20
> I've been having problems getting the repository to compile for about a
> week or so.  I finally got gimp 1.1.21 downloaded and compiled (a story
> all by itself), but have still been unsuccessful.  I get the following
> error:
> checking for GIMP - version >=3D 1.0.0... no
> *** Could not run GIMP test program, checking why...
> *** The test program failed to compile or link. See the file config.log
> for the
> *** exact error that occured. This usually means GIMP was incorrectly
> installed
> *** or that you have moved GIMP since it was installed. In the latter
> case, you
> *** may want to edit the gimptool script: /usr/local/bin/gimptool
> configure: error: Cannot find GIMP libs: Please run ldconfig
> make: *** [config.status] Error 1
> print>=20

The file config.log should tell you exactly what went wrong. Can you=20
check the last few lines in this file. This contains most likely a short
C program plus a command to compile it. When you copy/paste the program
to a test.c file and manually compile this file you should see the
problems configure has with your own eyes (andnot just through the=20
configure filter).

Karl Heinz

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

Re: [Gimp-print-devel] Compilation error (was: Andy or Mitch, please read the Help forum)

[Sven N. <neu...@un...>]

Hi,

> I've been having problems getting the repository to compile for about a
> week or so.  I finally got gimp 1.1.21 downloaded and compiled (a story
> all by itself), but have still been unsuccessful.  I get the following
> error:
> checking for GIMP - version >= 1.0.0... no
> *** Could not run GIMP test program, checking why...

The standard cause of this problem is that you didn't run ldconfig
after installing a new version of gimp. That's why the output 
mentions it:

> configure: error: Cannot find GIMP libs: Please run ldconfig

Does that help in your case ?


Salut, Sven

Re: [Gimp-print-devel] More stuff

[Ron v. O. <R.A...@Wb...>]

Robert L Krawitz wrote:
> 
>    Date: Thu, 04 May 2000 12:57:49 +0200
>    From: Ron van Ostayen <R.A...@Wb...>
> 
>    Quality   Time(s)  FileSize     Printing time (time cat tiger0..9.prn >
>    /dev/lp0)
>      0        33.2     1986522       18.5  OK but top margin is approx
>    0.9cm smaller than for other settings.
>      1       112.1     7118815       68.0  OK
>      2       110.6     7118808       error in output (empty pages and
>    garbage)
>      3       116.1         955 !!
>      4      signal 11
>      5       191.5     9977020      121.0  OK
>      6       190.2         605 !!
>      7       198.7        2042 !!
>      8       356.4        2127 !!
>      9       390.9        1549 !!
> 
>    I have succesfully tested 3.1.3 with quality setting 0,1,2,3,5,6 and 8
>    so the last changes seem to have broken some settings.
> 
> Could you retest settings 2, 3, and 6?

I have, and they are still broken.  The output file sizes are not
exactly the same, but mode 2 still produces blank and garbage pages, and
modes 3 and 6 produce small files.

> 
> BTW, were you using ordered dither (dither=1)?  I think that might
> account for the file size of 3, 6, 7, 8, and 9.  That bug should be
> fixed.  Try dither=2 (random Floyd-Steinberg) and dither=4 (adaptive
> random Floyd-Steinberg).

I have used the default dither (dither=0?).
Dither=2 doesn't change the result.

> 
> I know the rendering time is awful...please bear with this for a while
> longer...
> 
> --
> Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/
> 

Ron van Ostayen
R.A...@Wb...
Laboratory of Tribology
Department of Mechanical Engineering
University of Technology Delft

Re: [Gimp-print-devel] More stuff

[Ron v. O. <R.A...@Wb...>]

Robert L Krawitz wrote:
> 
>    Date: Thu, 04 May 2000 16:11:01 +0200
>    From: Ron van Ostayen <R.A...@Wb...>
> 
>    > One pass, and bidirectional.
> 
>    Now I'm confused.  The printer head goes across the page dumping ink,
>    and returns dumping ink.  Then the paper is moved forward approx. 1.4cm.
> 
> Hmm.  I see what you mean.  At 360 dpi, the 900 prints *every* row.
> In theory, at any rate.
> 
>    I would call this 2-pass, bidirectional?
> 
>    The windows driver uses a mixed approach:  When color is needed it uses
>    the same approach as gimp-print but when (black) text or figures are
>    printed then the head goes across the page dumping ink, the
>    paper is moved forward 1.4cm, the head returns dumping ink, and the
>    paper is moved forward approx. 1.4cm.
> 
>    I would call this 1-pass, bidirectional?
> 
> OK, I think I have a clue what's going on here.
> 
> You'll find this in print-escp2.c:
> 
>   if (use_glossy_film)
>     dither_set_black_upper(dither, 1.0);
>   else
>     dither_set_black_upper(dither, 1.0);
> 
> Try changing the 1.0 to .99 (make it less than one by greater than one
> part in 65536).  See if that makes a difference.  What *may* account
> for your problem is that even in pure black regions the driver's
> dropping some color ink.  If that doesn't work, try printing something
> with -dColor=0 as a test.  This will print black ink only.

The latest version I got from the repository has a value of 0.999.
And yes, this works!!
Black images and text are printed in one pass like with the windows
driver.

I assume this will improve other resolution printout as well?

> 
>    Furthermore the windows driver uses a much faster method of paper
>    transport across empty areas.  The gimp-print driver is very slow across
>    empty areas.
> 
> I know.  I've partially optimized it, but not completely.  That
> shouldn't be all that hard to get right.  It's possible that what
> looks empty isn't entirely, but it's possible to figure that out from
> the print file, if what I eventually do to fix it doesn't solve the
> problem.

This seems to have been fixed also.
So it would seem that the 360dpi mode achieves the same printing speed
as the windows driver.
Now all that remains is to improve the dithering speed :-).

> 
>    And yet the windows printer dump file size is about 2x as large.
> 
> Now that's very interesting.  I wonder why.
> 
>    During rendering the difference is a more pronounced: Printing 10 pages
>    of my report to file takes about 20s in windows and 220s in gimp-print!!
> 
> Yeah, the dithering still needs some performance tuning...
> 
>    The quality of in particular the windows text is much better than the
>    gimp-print output.  Figures and photos are comparable.
> 
> What's the difference (more specifically)?

Well, I have studied a scan of the output and actually the difference
isn't that bad.
It's just that the windows driver uses more ink.  More black, more
color.
Which settings should I change to get this result?

> 
> --
> Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/
> 

Ron van Ostayen
R.A...@Wb...
Laboratory of Tribology
Department of Mechanical Engineering
University of Technology Delft

Re: [Gimp-print-devel] 3.2 or 4.0 Release criteria

[Thomas T. <tt...@bi...>]

Robert L Krawitz wrote:


>    No, I only put the gray cartridge, I chose UCR separation, correct
>    the saturation. and select "color ink".  The driver do separations
>    in CYMK and add the two extras layers for the ligth cyan and
>    magenta.  Choice of UCR should be better than GGR, but I don't
>    tried the two on the same picture.
> 
> What is UCR separation?  Why would you correct the saturation for
> printing black and white, which has no saturation?

UCR is 'Under Color Reduction'. GCR is 'Gray Component Reduction'. Both
have to do with using CMY instead of black, As far as I remember, GCR
uses more black, and UCR uses more CMY.

With offset printing both have a spec that gives the max ink level.

> Basically, what it sounds like is that the architecture of the Windows
> driver is simply different from ours.

As long as the grey inkt in each nozzle has the same darkness as the
Epson colored ink, this cartridge should give good results. When the
image is made black and white before it is printed, the results may be
even better.

But even better results could be obtained by using the knowledge that
cou can print from the light magenta nozzle without anything getting
magenta. So what it does in the 'Windows Scenario':

Light tints are built up from LC LM and Y - these are light greys.
Darker tints are built up from C M Y - these are medium greys (humm, Y
is out).
Darkest is built by K - which is really black. 

Desaturating your image allows skies to be printed with more 'M and Y'
which may work better than just 'C'. And you use the inks more evenly.

But a different separation, that knows CMY are not colores, sounds even
better.


Thomas

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

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

On Thu, 4 May 2000, Dave Hill wrote:

> The HP 6-ink printers are not supported, because I don't know how to
> drive them. What is needed is:-
> 
> 1/ The init commands to tell the printer that the data is CcMmYK.
> (i.e. the extra inks are Light Cyan and Light Magenta). Does this
> use the "Configure Raster Data" command (ESC * g <n> W), or just
> the "Simple Resolution" command (ESC * <n> R)? Maybe the "configure
> palette" command (ESC * d <n> W) has something to do with it?

The language of the 69x printers is PCL3, which means that they are very
similar to the 89x and the 1120 printers.  Like those printers, it must be
configured with the "configure raster data" command (ESC*g...W)
This is de entire string you need to send:
/* FILE * device = fopen( "/dev/lp0", "w" ); */
/* \xxx is an octal notation, as accepted by the printf instruction */
fprintf( device, "\033*g38W\002\006"     // 6 is for 6 inks
       "\002\130\002\130\000\002" // 600dpi, 2 dither levels for black
       "\002\130\002\130\000\002" // 600dpi, 2 dither levels for cyan
       "\002\130\002\130\000\002" // 600dpi, 2 dither levels for magenta
       "\002\130\002\130\000\002" // 600dpi, 2 dither levels for yellow
       "\002\130\002\130\000\002" // 600dpi, 2 dither levels for lcyan
       "\002\130\002\130\000\002" // 600dpi, 2 dither levels for lmagenta
       );
for 300dpi printing, just replace the "\002\130" with "\001\054"

To start printing, I usually only send the following list of commands:
 - Reset (ESC E)
 - SkipPerforation(don't skip)
 - Page Format (A4)
 - SetRasterWidth(ESC * r number_of_pixels_per_dataline S)
 - SetMediaType(glossy, or plain, or ...)
 - ConfigureRasterData(6 inks, each 600dpi, 2 dither levels)
            (note that unlike the 89x and 1120, who have 4 dither levels,
             the 69x has only 2 dither levels)
and that's it.  After the configure raster data command, you can
immediately start sending the raster data using the send plane commands.
The send plane commands expect ( number_of_pixels_per_dataline + 7 ) / 8
bytes of data per plane (or per ink).
 
> 2/ The order of the planes to be sent to the printer in the "send
> plane" commands (ESC * b <n> V and ESC * b <n> W).

This follows the same order as I indicated in the configure raster data
command : black, cyan, magenta, yellow, light cyan, light magenta.

Henk Verleye

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

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

Henk Verleye wrote:
> 
> In the supported printer list for the gimp-print project, the HP DeskJet
> 600 series is there.  Does this also include the 690 series (= a 6 ink
> printer, similar to the Epson Stylus Photo series, only with a HP PCL
> interface) ?
> If not, what do you need to add it (the printer codes? information about
> the colour of the inks? other things?)?
> I may be able to deliver most of what's needed.
> I haven't taken any look into the code itself, so at this point in time I
> cannot add the HPDJ690c (should it be lacking) myself, but I may be able
> to do it in the future, if needed (at one time I already made a linux
> driver for that printer, but that was outside the GNU community; if I
> receive the data in a colour-separated and dithered form, I'm able get
> things through to the printer).
> 

Hi Henk,

The HP 6-ink printers are not supported, because I don't know how to
drive them. What is needed is:-

1/ The init commands to tell the printer that the data is CcMmYK.
(i.e. the extra inks are Light Cyan and Light Magenta). Does this
use the "Configure Raster Data" command (ESC * g <n> W), or just
the "Simple Resolution" command (ESC * <n> R)? Maybe the "configure
palette" command (ESC * d <n> W) has something to do with it?

2/ The order of the planes to be sent to the printer in the "send
plane" commands (ESC * b <n> V and ESC * b <n> W).

and that's it. 

If you can help, I will be grateful. I have tried asking HP, so
far no answer!

Regards
Dave Hill
HP driver maintainer.

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