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