gimp-print-devel

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

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

sh...@al... wrote:
> 
> It could be determined even more conclusively by using the Windows driver
> to print to a file and then disassembling the printer instructions in that
> files.  It's a relatively simple job to do this.
> 

This sounds like a good idea.  Personally, I'm not adept at
reading the escp2 command language, but if doing this might 
help debug the 1440dpi microweave and softweave problems, I 
will do it and post the files here.

-David

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

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

> Maybe this can be determined by a timing experement with the
> windows driver.

It could be determined even more conclusively by using the Windows driver
to print to a file and then disassembling the printer instructions in that
files.  It's a relatively simple job to do this.

Eric

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

Printer specific Option Choices [ was Re: [Gimp-print-devel] RE: Epson 1520 issues ]

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

Robert L Krawitz <rl...@al...> said: 
[ ... ]
> 
> 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).

Before we go out and use these functions from PDQ, we should try
to understand exactly what we need. 

We are already using some degree of printer specific options for 
PostScript devices. This means that a rudimentary PPD parser is
already in the plugin code. PPDs are of course very PostScript 
specific and it probably does not make a lot of sense to use them
without modifying the concept a little bit. Just in case you are
not familiar with the PPD concept, here's a very brief introduction:

Adobe uses PPDs for PostScript printers to create a common device
driver interface for both Windows and Macs. The PPD files contain
information about which commands need to be send to the printer in
order to select a feature. So if you want to have your document 
printed duplex you (or your driver) looks through the PPD file until
you find the Duplex setting and just send down the string that's
listed to the printer. Pretty easy and straight forward. Now what
makes PPDs really interesting is their connection to the GUI. For
every feature there is information about how to display the selection
dialog, the strings to use for the options and lots of information
about constraints. These constraints are rules identifying conditions
when a certain option can be displayed or can not be displayed. It
does e.g. not make a lot of sense to select to print on transparency
material in duplex mode. So the PPD has some mechanisms in place to
identify these conditions so that the driver can disallow them.

The CUPS project has a full blown PPD parser.

Another solution that we should look at is using XML to define the
printer specific options. Again, we already have a parser that can
handle XML files.

Regardless of which format we use to identify the printer specific
options, we still need two things: A user interface concept that 
can deal with these options and a way to communicate the settings
to the plugin which then will use some kind of logic to decide what
to send to the printer. If we want to be really generic then this
sounds like we also need some kind of extension language that can
be used to create small (or not so small) procedures that will be
called from within the plugin to "compute" the commands we need
to send to the printer.

Any comments?

Karl Heinz

[Gimp-print-devel] Ordered dither

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

I've committed some ordered dither code to a branch named
ordered-dither-branch (the branch point is ordered-dither-bp).  So if
anyone wants to play with the ordered dither code, I think I've
committed everything that's needed.

Warning: this code is somewhat of a mess.  It only works for Epson
Stylus printers right now.

[Gimp-print-devel] I need help!

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

I'm getting overloaded with stuff here, and I need some help from some
volunteers.

The basic subprojects here are:

1) Driver maintenance -- adding new printer drivers and all that.
   Some of this is fairly mechanical; some of it requires rooting
   around in printer output files; some of it requires some
   understanding of the internals of the print plugin.  It requires
   access to printers, a willingness to read often incomplete
   documentation, and a taste for reverse engineering (NOTE: "reverse
   engineering" in this context means reverse engineering of printer
   output or protocol ONLY.  I don't want anyone disassembling code.
   It normally shouldn't be necessary here.)

2) The dither code.  Hopefully we'll eventually get Raph's dither
   routine (which I've heard a lot of good things about); if not,
   we'll need to improve our stuff.  For people mathematically
   inclined, this can be a lot of fun.

3) Infrastructure.  Currently the set of options that can be passed to
   printer drivers is fixed.  We really don't want that.

4) Testing.  We need lots of it.  We cannot have too much testing.
   Anyone with a printer can and should do lots of it on a regular
   basis.  Most of the printer options can be set without requiring
   any coding (in printers.xml).

5) The GUI.  Currently this project is staffed (Steve Miller and Mitch
   Natterer), but if anyone else is interested in this, drop Steve or
   Mitch a note (or send it to the list).

6) The GhostScript driver.  Currently this only supports the Epson
   printers, for no particularly good reason.

If you're seriously interested in contributing to any of these
projects, and have appropriate skills, drop me a note describing what
you'd like to do and we can discuss adding you to the developer
roster.  If you'd like to test, you don't need anyone's permission at all.

-- 
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] RE: Epson 1520 issues

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

   Date: Tue, 28 Mar 2000 09:33:59 -0800
   From: David Rosky <dav...@ts...>

   Robert L Krawitz wrote:

   Another observation about 1440dpi:  When the Windows driver
   is printing in 1440x720dpi, the head moves across the page at
   about half the speed as it does in 720dpi mode.  I assume it
   does this in order to achieve the 1440dpi horizontal resolution
   using one horizontal head pass.

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.

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

   The upper margin of the printable area for the 1520 is supposed to 
   be 0.12".  When I place the image all the way against the top margin 
   in the gimp-print dialog box, I would expect the top edge of the 
   image to be somewhere around 0.12" from the top of the page, plus 
   or minus some amount for paper alignment errors.  With the Windows
   driver, this is generally what I get.  With the gimp-print driver,
   when using the working 720dpi microweave mode, the top
   of the image is somewhere around 0.5" to 0.75" from the top of
   the page.

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.

-- 
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] RE: Epson 1520 issues

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

Robert L Krawitz wrote:
> 
> Actually, in softweave mode it should be alternating between several
> small advances and one larger advance, although normally they're
> fairly close to equal in spacing.  

OK.  If the difference between the small steps and the big
steps is not that great, then it might appear as if there 
is only one size step.

> The fact that there's a difference
> between the positioning of the softweave and the microweave is
> probably an artifact of the fact that the softweave isn't correct.

I figured that might be the case, which is why I thought it 
might be a notable symptom to report.  Apparently the softweave 
code was taking four microscopic or zero sized steps (hard to 
tell the difference at 720dpi!) followed by one huge step.

Another observation about 1440dpi:  When the Windows driver
is printing in 1440x720dpi, the head moves across the page at
about half the speed as it does in 720dpi mode.  I assume it
does this in order to achieve the 1440dpi horizontal resolution
using one horizontal head pass.

> What do you mean about the image being lower than one would assume
> from the print dialog?
> 

The upper margin of the printable area for the 1520 is supposed to 
be 0.12".  When I place the image all the way against the top margin 
in the gimp-print dialog box, I would expect the top edge of the 
image to be somewhere around 0.12" from the top of the page, plus 
or minus some amount for paper alignment errors.  With the Windows
driver, this is generally what I get.  With the gimp-print driver,
when using the working 720dpi microweave mode, the top
of the image is somewhere around 0.5" to 0.75" from the top of
the page.  I am away from the printer right now, so I'm not sure
of the exact number, but I can make an exact measurement for you
in a few days.  I'll also double-check the windows results (I
haven't printed from windows for a while) and double check that 
the printer is loading the paper correctly.

-David

Re: [Gimp-print-devel] HPdj694c Photoink...

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

   Date: Mon, 27 Mar 2000 12:59:24 +0100
   From: Dave Hill <da...@mi...>

   An alternative is, as you say, to look at the PCL data. I have
   written "pcl-unprint" for this, but it may not work on data
   produced by anything other than gimp-print!

pcl-unprint isn't the way to go here.  Someone needs to write a script
or program analogous to parse-escp2 that simply parses the output
syntactically without ascribing any semantics to it.  Then you can try
to duplicate what comes out.

-- 
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] RE: Epson 1520 issues

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

Robert L Krawitz wrote:
> 
> 
> Let me know how it works now.
> 

Will do, thanks.  It'll be a few days, though,
until I'm back at the computer with the 1520
attached.

David

Re: [Gimp-print-devel] HPdj694c Photoink...

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

Hi Andreas,

I wasn't inferring that you would know the answers to the
questions, I was just posing them so you had an idea of
what was required to get it to work.

The question regarding dithers may be answered in the user
manual that came with the printer (but I doubt it!).

I am trying to join the HP Solution Provider program to see
if the documentation is available.

An alternative is, as you say, to look at the PCL data. I have
written "pcl-unprint" for this, but it may not work on data
produced by anything other than gimp-print!

Since I don't have a 694 printer, I can only suggest what to
look for B-).

Regards
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] RE: Epson 1520 issues

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

   Date: Sun, 26 Mar 2000 22:22:51 -0800
   From: David Rosky <d_...@nc...>

   1) It's much much slower than the 720x720 microweave - it
   seems to be using only one or two nozzles as the paper
   advances microscopically with each pass.  At first I 
   thought the paper wasn't moving at all.

Let me know how it works now.

-- 
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] RE: Epson 1520 issues

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

   Date: Sun, 26 Mar 2000 21:32:04 -0800
   From: David Rosky <d_...@nc...>

   In softweave, the head makes four passes before advancing
   the paper.  In microweave mode, the driver places the image
   about 1cm or so lower on the page than in softweave mode
   (letter, portrait); and in both cases, the image is somewhat
   lower than one would assume from the print dialog.  This 
   doesn't happen when printing from Windows applications, so
   I assume it is not a printer issue.

Actually, in softweave mode it should be alternating between several
small advances and one larger advance, although normally they're
fairly close to equal in spacing.  The fact that there's a difference
between the positioning of the softweave and the microweave is
probably an artifact of the fact that the softweave isn't correct.
What do you mean about the image being lower than one would assume
from the print dialog?

-- 
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] RE: Epson 1520 issues

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

   Date: Sun, 26 Mar 2000 22:22:51 -0800
   From: David Rosky <d_...@nc...>

   1) It's much much slower than the 720x720 microweave - it
   seems to be using only one or two nozzles as the paper
   advances microscopically with each pass.  At first I 
   thought the paper wasn't moving at all.

That's what happens on the EX.  The sequence in which the data is sent
in microweave mode is not optimal, particularly for 1440x720.

   2) The image appears expanded by about 3x in the vertical
   dimension only.  The expansion appears to be such that the
   vertical spacing between dots is also expanded, resulting
   in a decrease in overall density.

Hmm.  That's very interesting.

   If fast microweave is only possible in 720x720, then
   unfortunately softweave may still be needed :(

If so, you're going to need to test it.  Try changing the "8" in the
"64,8" to other values between 1 and 16 to see if anything else gives
you better results.

-- 
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] RE: Epson 1520 issues

[David R. <d_...@nc...>]

Robert L Krawitz wrote:
> 
> OK, I've reenabled 1440x720 microweave.  Let me know how it does.
> It's hideously slow on my EX.
> 

Thanks for the fast turnaround.  I tried it but it doesn't
seem to be completely working yet.  Here are the issues:

1) It's much much slower than the 720x720 microweave - it
seems to be using only one or two nozzles as the paper
advances microscopically with each pass.  At first I 
thought the paper wasn't moving at all.

2) The image appears expanded by about 3x in the vertical
dimension only.  The expansion appears to be such that the
vertical spacing between dots is also expanded, resulting
in a decrease in overall density.

3) The colors seem to be much more red-ish.  This may be an
artifact due to the decrease in density caused by item 2, but
I'm not sure of that.


If fast microweave is only possible in 720x720, then
unfortunately softweave may still be needed :(

I'll be away from my printer for the next few days, but I'll
check the list for any developments.

-David

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

[David R. <d_...@nc...>]

Robert L Krawitz wrote:
> 
> 
> Could you time it with a stopwatch and verify that the times really
> are about equal (or that microweave does better)?
> 

OK, here are the timings.  The image is 1272x1007 pixels and
was being printed at about 42% scale (resulting image was
about 9cm x 7.5cm).  The machine is a 233MHz pentium Pro:

MODE              PROCESSING TIME     PRINTING TIME  TOTAL TIME
720x720 microweave   40 sec.             62 sec.       102 Sec.
720x720 softweave    40 sec.             101 sec.      141 Sec.

As I had noticed previously, the microweave mode is somewhat
faster.

A few additional observations:

In softweave, the head makes four passes before advancing
the paper.  In microweave mode, the driver places the image
about 1cm or so lower on the page than in softweave mode
(letter, portrait); and in both cases, the image is somewhat
lower than one would assume from the print dialog.  This 
doesn't happen when printing from Windows applications, so
I assume it is not a printer issue.

Regards,

David

Re: [Gimp-print-devel] HPdj694c Photoink...

[Andreas E. <A.E...@bi...>]

Dave Hill <da...@mi...> wrote:

> As Robert says, the dithering support is all present, it just
> needs the "nuts and bolts" bits sorting out.
sounds good :_)
> What are the two extra colours - I assume they are "light magenta"
> and "light cyan".
right.
> How do you tell the printer to expect the extra colour planes? This
> could be what the "configure palette" command is for, or it may be
> coded in the "configure raster data" command. Neither of these is
> documented by HP as far as I can tell.
one would think that reverse engineering the raw HPCL data shouldn't be too
difficult ? %-)
> What order are the planes to be sent to the printer? For normal
> colour, they are sent in the order "KCMY", is it now "KCcMmY", or
> maybe "KCMYcm"?
There aren't too many possibilities there,
so best one could just test it out :-)
> Does the photo mode support more than 2 level dithers (like the
> 800 series)?
How,exactly would I come to know about that ?
> Other than that, it should be quite easy!
Gonna have a further look at it as soon as I got a replacement color cartridge
for that stupid printer - replacing all cartridges at once 
is more expensive than buying a new printer of the same type btw :-(

Andy

-- 

                -  Open Minds, Open Source, Open Software  -
	Linux, the number one operating system of the 21st century
	
		    

[Gimp-print-devel] dither stuff

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

I've been playing around with an ordered dither matrix, mostly for my
own edification, and it's producing interesting results, when my
printer cooperates (the lack of cooperation has nothing to do with the
dither pattern; it's a cartridge refill that I did this afternoon that
it seems unhappy about).  It produces somewhat interesting effects;
the dither pattern is very fine, but it produces fine diagonal lines
(not the error diffusion kind; it produces diagonals because I've
biased the matrix position to avoid horizontal and vertical lines).

A side effect is that the output files are much smaller than with
error diffusion.

I haven't put anything into the GUI for it.  Right now it's hardwired
into the Epson driver in my sandbox.  I could check it in if people
want to play with it.

-- 
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] RE: Epson 1520 issues

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

OK, I've reenabled 1440x720 microweave.  Let me know how it does.
It's hideously slow on my EX.

-- 
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] RE: Epson 1520 issues

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

   Date: Sun, 26 Mar 2000 16:35:02 -0800
   From: David Rosky <d_...@nc...>

   > OK, I guess we`ll get rid of softweave mode on the 1520.

   That sounds kind of drastic, but I suppose if high speed microweave
   is supported by a given printer, it might obviate the need for
   softweave with that printer.  I wonder the same issues would also
   apply to similar genre printers like the stylus color 800 and 850?

If we can make softweave work, I'll happily put it back in, but if
not, we can't use it.

   Again, I'm not an expert at printer internals, but in case it might
   help, here's something I observed when testing the driver: When
   using the microweave mode, the printer advances the paper a small
   amount after every pass of the print head, whereas when using
   softweave, several passes (either three or four, I can't remember
   right now) are done before the paper is advanced; and when it is
   advanced, it is advanced the same small amount as it is during
   microweave.  This probably accounts for the perceived speed
   difference - making microweave seem 3-4 times faster than
   softweave.

Could you time it with a stopwatch and verify that the times really
are about equal (or that microweave does better)?

   >I know what`s wrong with the 1440x720 microweave.  The fix won`t
   >be that hard, but it`s not entirely trivial either.  It looks like
   >this really will need fixing.

   Once again, let me know when you have taken a cut at it and I'll
   test it out.  For two years I've been looking forward to the moment
   I could print out a photo at 1440x720 from Linux and have it be as
   good as the same printed from Windows..

I'm working on it right now.

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

[David R. <d_...@nc...>]

> OK, I guess we`ll get rid of softweave mode on the 1520.

That sounds kind of drastic, but I suppose if high speed
microweave is supported by a given printer, it might
obviate the need for softweave with that printer.  I
wonder the same issues would also apply to similar
genre printers like the stylus color 800 and 850?

Again, I'm not an expert at printer internals, but 
in case it might help, here's something I observed when 
testing the driver:  When using the microweave mode,
the printer advances the paper a small amount after every
pass of the print head, whereas when using softweave, several 
passes (either three or four, I can't remember right now) are 
done before the paper is advanced; and when it is advanced,
it is advanced the same small amount as it is during
microweave.  This probably accounts for the perceived
speed difference - making microweave seem 3-4 times
faster than softweave.

>I know what`s wrong with the 1440x720 microweave.  The fix won`t be
>that hard, but it`s not entirely trivial either.  It looks like this
>really will need fixing.

Once again, let me know when you have taken a cut at
it and I'll test it out.  For two years I've been
looking forward to the moment I could print out a
photo at 1440x720 from Linux and have it be as good
as the same printed from Windows..

Regards,

David

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

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

   Date: Sun, 26 Mar 2000 10:25:42 -0800
   From: David Rosky <d_...@nc...>

   I tried changing the nozzle separation to 4, but the the softweave
   mode still seems to be printing some raster lines on top of each
   other while leaving wide gaps between the bands of printed lines,
   just in a slightly different way than before.

OK, I guess we'll get rid of softweave mode on the 1520.

   The quality if the 720x720 microweave mode, however, is *very* good
   - as good or better than the windows driver; and if anything, seems
   to print faster than the softweave mode.  As you point out, the
   1520 must have a faster processor and more memory than the newer
   models.

Weird, isn't it?

   My C development skills are not very good, but I am more than happy
   to test out any code changes you might suggest, including any fixes
   to the broken 1440x720 microweave mode.  Unfortunately, I don't
   have a working flatbed scanner right now, but I can snail-mail the
   output of the various modes on my printer if this would help.

I know what's wrong with the 1440x720 microweave.  The fix won't be
that hard, but it's not entirely trivial either.  It looks like this
really will need fixing.

-- 
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] Epson 1520 issues

[David R. <d_...@nc...>]

As per your request, I will follow up this issue here
in the gimp-print-devel list.

I tried changing the nozzle separation to 4, but the
the softweave mode still seems to be printing some
raster lines on top of each other while leaving
wide gaps between the bands of printed lines, just
in a slightly different way than before.

The quality if the 720x720 microweave mode, however,
is *very* good - as good or better than the windows
driver; and if anything, seems to print faster than
the softweave mode.  As you point out, the 1520
must have a faster processor and more memory than
the newer models.

My C development skills are not very good,
but I am more than happy to test out any
code changes you might suggest, including any
fixes to the broken 1440x720 microweave mode.  
Unfortunately, I don't have a working flatbed scanner
right now, but I can snail-mail the output of the 
various modes on my printer if this would help.

Regards,

David

[Gimp-print-devel] Re: Membership in HP Solution Provider Program

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

Eddie Maddox wrote:
> Dave, could you, the Ghostscript maintainer, and any others who wish give
> this a try? And let us all know if all the latest PCL docs are revealed?
> 

I'll have a look into it. I just hope that any info can be used in
a GPL'ed program.

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] HPdj694c Photoink...

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

Andreas Eckleder wrote:
> 
> Hi there !
> 
> What about supporting HP's photoink set of the 600 series.
> It works pretty much the same as with that epson printer
> already supported by gimp-print,
> namely by providing two additional colors.
> I'd love to help with development as good as I can,but I've never done
> dithering etc. before.
> Unfortunately,HP does no longer explain their computer->printer protocol
> (PCL) in their manuals as they did with the 500 series.
> 
> Andy

Hi Andy

I must have missed your message when you sent it, I have just found
it lurking in the far corners of my inbox.

As Robert says, the dithering support is all present, it just
needs the "nuts and bolts" bits sorting out.

What are the two extra colours - I assume they are "light magenta"
and "light cyan".

How do you tell the printer to expect the extra colour planes? This
could be what the "configure palette" command is for, or it may be
coded in the "configure raster data" command. Neither of these is
documented by HP as far as I can tell.

What order are the planes to be sent to the printer? For normal
colour, they are sent in the order "KCMY", is it now "KCcMmY", or
maybe "KCMYcm"?

Does the photo mode support more than 2 level dithers (like the
800 series)?

Other than that, it should be quite easy!

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