Re: [Gimp-print-devel] RE: Epson 1520 issues

[David R. <dav...@ts...>]

Robert L Krawitz wrote:
> 
> 
> I *believe* that none of the printers can do 1440x720 in one pass;
> they all require (at least) two passes to do it -- some printers need
> four.  The fact that you're only seeing one pass of the print head is
> immaterial; the head uses different jets to print each sub-pass.  That
> reduces banding.  The slower print speed is simply something the
> driver tells the printer to do; presumably it improves quality
> somewhat.

Maybe this can be determined by a timing experement with the
windows driver.  If the print head is moving at half the speed and 
the horizontal printing is done in one pass, then a 1440x720dpi 
image should take around twice as long to print as the same image 
at 720x720dpi (assuming the processing is fast enough to keep 
the print head in motion continuously, which is the case on my 
machine).  If, however, two passes are required to print each 
horizontal raster line, then the 1440dpi image should take around 
four times longer to print (2x for the reduction in print head 
speed times 2x for the two passes).

In any case I agree, though, that it would be good to allow more 
print head settling time at 1440dpi than at 720dpi.

> 
> We really need a GUI (and a system architecture) that allows the print
> driver to pass arbitrary printer-specific option choices through to
> the user.  PDQ does a lot of this.  It would be nice to figure out a
> way to leverage PDQ or snarf some of its code (I think it's GPL).
> 

I wasn't familiar with PDQ, so I looked up its web page.  It seems
like a nice system and I think I'll try it out.  With respect to
gimp-print, since PDQ uses Ghostscript to render postscript, and
since gimp-print has a Ghostscript driver manifestation, wouldn't
the two already be able to work together?  Presumably, gimp-print
could receive printer-specific options from PDQ in the form of 
Ghostscript command line options. ??

> 
> That's a limitation of the driver in its current form.  I think I know
> how to get rid of that, although it will make for a bit more banding
> at the top, but it's going to be a fair bit of work to do.  It's
> definitely something I want to fix before 3.2.  It actually might be
> possible to get even closer than that, but let's do first things
> first.
> 

I agree, it's not a big limitation at this point and functionality
comes first.

-David