gimp-print-devel

[Gimp-print-devel] Print 3.1.1

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

Print 3.1.1 is out.  Please see http://gimp-print.sourceforge.net or
ftp://download.sourceforge.net/pub/sourceforge/gimp-print/print-3.1.1.tar.gz.

This is a development release.  The usual caveats apply.  We still
don't guarantee that the print head won't be launched from the printer
with *ahem* unpredictable results.

Print 3.1.1 contains the following improvements over Print 3.1.0:

1) Faster dithering speed.

2) Improved support for many Epson Stylus printers.

3) Some UI improvements.

4) Numerous bug fixes.

-- 
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] new printer parser

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

I've taken a stab at writing an XML parser for printer definitions
(not that I've written a formal DTD :-) ).  The files printdef.{h,l,y}
represent the header, flex, and bison inputs for this.  It's not in
the makefile yet, and it won't be in 3.1.1 (which hopefully I'll cut
tomorrow'ish).  To compile it:

flex -i printdef.l
bison -d printdef.y
cc -o printdef printdef.tab.c lex.yy.c

It generates C source.

[2(rlk)||{!1256}<rlkppp>/mnt/sandbox/gimp-print/print]
$ cat printer.sample
<printer name="Epson Stylus Photo EX" driver="escp2-ex">
<paramfunc value=escp2_parameters>
<imageableareafunc value=escp2_imageable_area>
<printfunc value=escp2_print>
<model value=9>
</printer>
[2(rlk)||{!1257}<rlkppp>/mnt/sandbox/gimp-print/print]
$ ./printdef < printer.sample
{
  {
    "Epson Stylus Photo EX",
    "escp2-ex",
    9,
    escp2_parameters,
    default_media_size,
    escp2_imageable_area,
    escp2_print,
    100,
    1.000,
    100,
    100,
    100,
    100,
    1.000,
    1.000
  },
}

-- 
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] The Truth Behind ESC ( D

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

   From: sh...@al...
   Date: Sat, 04 Mar 2000 18:41:10 +0900

   > But this still doesn't entirely add up.  The vertical spacing is a
   > hardware matter -- the jets are exactly such a distance a part, and no
   > amount of programming will change that.

   You are assuming softweave mode.  But what about in microweave?  Vertical
   resolution is determined solely by paper advances.  I would imagine that
   they have some sort of stepper motor that does the advancing, rather than
   a continuous motor with a timed pulse, so you couldn't support arbitrary
   resolutions, but, probably quite a few more than are currently supported.

True, although ESC(D isn't used in microweave mode:

$ hack-epson.new < 640-360.prn |more

00000000  1b  @ 
00000002  1b  @ 
00000004  1b  (  R 08 00 00 52 45 4d 4f 54 45 31  *P  *M *02 *00 *00 *00  *S  *N
 *03 *00 *00 *00 *01 
0000001e  1b *00 *00 *00 
00000022  1b  (  G 01 00 01 
00000028  1b  (  U 01 00 0a 
0000002e  1b  U 01 
00000031  1b  (  i 01 00 00 
00000037  1b *19  *1 
0000003a  1b  (  e 02 00 00 03 
00000041  1b  (  C 02 00 71 10 
00000048  1b  (  c 04 00 17 00 ca 0f 
00000051  1b  (  S 08 00 a0 0b 00 00 71 10 00 00 
0000005e  1b  (  v 02 00 0d 00 

Of course, given what you say below, it suddenly makes a lot more sense.

   I don't know.  It's weird.  What I imagine is that none of the
   existing printers can really make use of this command because the
   stepper motors controlling paper feeds can't handle it, but, Epson
   is preparing for a long term strategy.  There are probably some
   fancy printers in R&D now that can or may support this kind of
   thing and Epson is laying the groundwork in software early.

   This is, of course, all rampant and baseless speculation, but, it does
   seem to be consistent with the fact that someone at Epson obviously thought
   there was some need to keep this command secret.

That makes more sense than anything else I can come up with.

-- 
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] The Truth Behind ESC ( D

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

> But this still doesn't entirely add up.  The vertical spacing is a
> hardware matter -- the jets are exactly such a distance a part, and no
> amount of programming will change that.

You are assuming softweave mode.  But what about in microweave?  Vertical
resolution is determined solely by paper advances.  I would imagine that
they have some sort of stepper motor that does the advancing, rather than
a continuous motor with a timed pulse, so you couldn't support arbitrary
resolutions, but, probably quite a few more than are currently supported.

> Unless by programming a
> multiple of that you can turn off some of the jets?  But to what end?

I don't know.  With RLE, you can zero out the line for a nozzle in just a
few bytes, so, turning off a nozzle is cheap in terms of the amount of
data you need to send over the bus, but, what does the printer do with
that data when it is received?  Is it kept RLE and decoded on the fly
as the head moves?  Or is it decoded into a RAM buffer before a pass?
I suspect the latter.

If you need to decode first, then, you can support longer lines by
turning off jets since you won't need to allocate buffer space for all those
zeros.

Why do you want to turn off jets?  The only reason I could think of would
be if you wanted to print at a resolution was not an integer multiple of
the jet spacing.  The 750 has a jet spacing of 6/720 or 1/120.  360,
720, and 1440 are multiples of the jet spacing with factors of 3, 6, and 12.
But what if you want to print at a resolution like 1140 DPI?  That's 9.5*120.
The first jet can print a line, but, the second jet cannot.  It's not
positioned properly.  But the third jet can! You can actually use 24
of the 48 jets to achieve 1140 DPI assuming you can advance the paper
that precisely.

I don't know.  It's weird.  What I imagine is that none of the existing
printers can really make use of this command because the stepper motors
controlling paper feeds can't handle it, but, Epson is preparing for a
long term strategy.  There are probably some fancy printers in R&D now
that can or may support this kind of thing and Epson is laying the groundwork
in software early.

This is, of course, all rampant and baseless speculation, but, it does
seem to be consistent with the fact that someone at Epson obviously thought
there was some need to keep this command secret.
   
> The separations computed from the ESC(D
> commands that we've seen don't match up to the print resolution.

Yes, I do have to admit that that one perplexes me.  When I get home
I'll play with this command a bit more.

Eric

Re: [Gimp-print-devel] The Truth Behind ESC ( D

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

   From: sh...@al...
   Date: Fri, 03 Mar 2000 21:23:05 +0900

   Seriously, though, this makes some sense.  In designing the new printer
   protocols, they simply moved the printer resolution from each individual
   raster transfer to once in the header.  It's a sensible thing to do.

But this still doesn't entirely add up.  The vertical spacing is a
hardware matter -- the jets are exactly such a distance a part, and no
amount of programming will change that.  Unless by programming a
multiple of that you can turn off some of the jets?  But to what end?

It makes more sense in the horizontal direction, where inter-droplet
separation has a certain amount of logic behind it, but even there
it's a hardware matter.  The separations computed from the ESC(D
commands that we've seen don't match up to the print resolution.

-- 
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] The Truth Behind ESC ( D

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

> There's something here that doesn't make a lot of sense.  Why on earth
> does anyone need to *set* the printer resolution, anyway?  Isn't it
> fundamentally a property of the printer hardware?

Nope.  You figured it out.  That's the trade secret.  It's Epson's new
adjustable with print head.  I just issued the ESC ( D 0xff 0xff 0x01 0x01
command and printed out a new microprocessor microlithography mask at
65535 DPI.  Epson doesn't want you to know that their printers can support
this resolution, since they were planning on gradually re-releasing the
same printer over and over again, over the next 10 years, with just a
simple software change to support higher and higher resolutions.  In
fact, it was so secret, they didn't even tell their developer relations
staff.  Now they're ruined.


Seriously, though, this makes some sense.  In designing the new printer
protocols, they simply moved the printer resolution from each individual
raster transfer to once in the header.  It's a sensible thing to do.

Eric

Re: [Gimp-print-devel] Performance

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

> Well, the error values are all ints.  Making them longs would consume
> more memory.

It's hard to predict that.  Compilers often align variables to start on
word boundaries anyway, so, memory usage would be the same if that was done.
For variables which don't exist on a word boundary, you need to do a shift
after loading the word into a register, which is why compilers tend not
to use them.

> The performance cost would probably be less on a 64-bit
> CPU (if it supports 64-bit arithmetic), though.

The only common 64 bit systems that I know of are the Alpha and the
Ultrasparc.  Both of these systems support 64 bit arithmetic.  I don't know
much about IA64.

Eric

Re: [Gimp-print-devel] The Truth Behind ESC ( D

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

   Date: Thu, 2 Mar 2000 19:24:12 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   It looks like nL=3D64 an nH=3D56 it is very easy to create all the
   resolutions:

   v or h -> resolution
   120		1 / 120
   40		1 / 360
   20		1 / 720
   10		1 / 1440

   The static string in print-escp2.c uses a vertical resolution of=20
   1/360 and a horizontal resolution of 1/120.=20

I'm going to fix that using the information in the table (but I
probably won't test it beyond simply compiling it when I commit it).

   Is it possible that this is the reason why the STC740 has a
   MODEL_MAKE_XRES(360) in it's capabilities? This makes it impossible
   to get to the 'good' 1440dpi modes with this printer, whereas the
   640 does allow to use these modes. This is of course a bit unfair
   to the owners of the more expensive printer :-)

1440 dpi should still work on the 740...1440 dpi "highest quality"
won't, but 1440 dpi softweave with 360 horizontal resolution is the
same as 1440 dpi highest quality with 720 horizontal resolution.  It's
four passes either way, which should hide just about all banding.

   Is there anything I can try to prove this theory? I don't really
   understand what the driver is doing with all these different
   resolutions, so I probably need some theory first...

I'll try to write something up over the next few days...

Re: [Gimp-print-devel] The Truth Behind ESC ( D

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

It looks like nL=3D64 an nH=3D56 it is very easy to create all the
resolutions:

v or h -> resolution
120		1 / 120
40		1 / 360
20		1 / 720
10		1 / 1440

The static string in print-escp2.c uses a vertical resolution of=20
1/360 and a horizontal resolution of 1/120.=20

Is it possible that this is the reason why the STC740 has a
MODEL_MAKE_XRES(360) in it's capabilities? This makes it impossible
to get to the 'good' 1440dpi modes with this printer, whereas the
640 does allow to use these modes. This is of course a bit unfair
to the owners of the more expensive printer :-)

Is there anything I can try to prove this theory? I don't really
understand what the driver is doing with all these different
resolutions, so I probably need some theory first...

Karl Heinz

On Thu, Mar 02, 2000 at 10:38:22AM -0500, Karl Heinz Kremer wrote:
> I just received this information from EPSON regarding the ESC ( D
> command:=20
>=20
> >=20
> > The ESC (D command is supposed to be "secret".  That is, we cannot
> release
> > information on it without a Non-Disclosure Agreement.  However, by
> looking
> > at a description of the command, I cannot justify withholding it.=20
> It
> > doesn't make sense to me that knowing how to use this command will
> allow the
> > public in on a trade secret of any kind.  If anything, it will allow
> us to
> > capitalize on the talents of the Linux community to develop better
> drivers
> > for us.  Our liaison from Japanese HQ agrees with me.  So here is
> the info
> > you wanted.
> >=20
> > ESC (D nL nH rL rH v h			[Set resolution of raster image]
> > nL=3D04H, nH=3D00H
> > 0<=3Dv<=3D127
> > 0<=3Dh<=3D127
> > vertical resolution is v/(rH*256+rL) inch
> > horizontal resolution is h/(rH*256+rL) inch
> > available resolutions are (depending on model):
> > 	1/120, 1/180, 1/360, 1/720, 1/1440
>=20
>=20
> Karl Heinz

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

Re: [Gimp-print-devel] The Truth Behind ESC ( D

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

   Date: Thu, 2 Mar 2000 10:42:53 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   > The ESC (D command is supposed to be "secret".  That is, we
   > cannot release information on it without a Non-Disclosure
   > Agreement.  However, by looking at a description of the command,
   > I cannot justify withholding it. It doesn't make sense to me that
   > knowing how to use this command will allow the public in on a
   > trade secret of any kind.  If anything, it will allow us to
   > capitalize on the talents of the Linux community to develop
   > better drivers for us.  Our liaison from Japanese HQ agrees with
   > me.  So here is the info you wanted.

Well, this is a win for everybody concerned, or at least for Epson,
Linux users in general, and us.  I'm glad to see Epson taking steps
like this.  This will definitely give them a competitive advantage
(until the other printer companies figure out that doing this is in
their best interests, too).

   > ESC (D nL nH rL rH v h			[Set resolution of raster image]
   > nL=04H, nH=00H
   > 0<=v<=127
   > 0<=h<=127
   > vertical resolution is v/(rH*256+rL) inch
   > horizontal resolution is h/(rH*256+rL) inch
   > available resolutions are (depending on model):
   > 	1/120, 1/180, 1/360, 1/720, 1/1440

Very interesting.  From two output samples from a 750 (one at 720, and
one at 1440), I got this:

00000083  1b  (  D 04 00 40 38 78 28 

These numbers correspond to

r = 14400
v = 120		(1/120", or 6 rows)
h = 40		(1/360")

Both a 640 and a 740, at 720 dpi, give the same numbers.

Another printer (a 900, I think), gives:

00000083  1b  (  D 04 00 40 38 28 28 

That corresponds to v = h = 1/360".

Somebody else (might have been me) reported these results:

> 1) ESP750, 1440 DPI:	00000083  1b  (  D 04 00 40 38 78 28 
> 2) ESP750,  720 DPI:	00000083  1b  (  D 04 00 40 38 78 28 
> 3) ESP900,  360 DPI:	0000008a  1b  (  D 04 00 40 38 28 28 (grayscale)
> 4) ESP900,  720 DPI:	0000008a  1b  (  D 04 00 40 38 28 50 (grayscale)
> 5) ESP900, 1440 DPI:	0000008a  1b  (  D 04 00 40 38 28 50 (grayscale)

There's something here that doesn't make a lot of sense.  Why on earth
does anyone need to *set* the printer resolution, anyway?  Isn't it
fundamentally a property of the printer hardware?

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

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

   From: sh...@al...
   Date: Thu, 02 Mar 2000 21:51:06 +0900

   > I did a round of performance tuning tonight.  Essentially, I got rid
   > of all but a very few uses of long long; the performance improvement
   > is about 40%.

   Hmm, I'm surprised it made that much of a difference.

Well, 32-bit arithmetic (add/subtract, at any rate) is one machine
instruction; 64-bit arithmetic is more involved.

   Anyway, from a performance point of view, wouldn't it have made more sense
   to go from long long to just plain long, rather than int?

   For i386, long and int are equivalent, but, on systems with 64 bit CPU's,
   long is equivalent to long long, but, these are precisely the same CPU's
   that won't take the same performance hits for using long long that the
   i386's do.

Well, the error values are all ints.  Making them longs would consume
more memory.  The performance cost would probably be less on a 64-bit
CPU (if it supports 64-bit arithmetic), though.

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

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

   Date: Thu, 02 Mar 2000 12:46:22 +0000
   From: Dave Hill <da...@mi...>

   Dithering still seems to be working OK.

   However, any attempt to print RGB or RGBA images in mono now results
   in the plugin dying with seg faults. I backed out the changes
   to print-util.c back to 1.78 and it works (but with the RGBA bug).
   I changed the "255" to "2550" and it still works.

The number had nothing to do with it; 25500 would have done the right
thing.  In any event, that silly bug is now fixed.

-- 
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] The Truth Behind ESC ( D

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

I just received this information from EPSON regarding the ESC ( D
command: 

> 
> The ESC (D command is supposed to be "secret".  That is, we cannot
release
> information on it without a Non-Disclosure Agreement.  However, by
looking
> at a description of the command, I cannot justify withholding it. 
It
> doesn't make sense to me that knowing how to use this command will
allow the
> public in on a trade secret of any kind.  If anything, it will allow
us to
> capitalize on the talents of the Linux community to develop better
drivers
> for us.  Our liaison from Japanese HQ agrees with me.  So here is
the info
> you wanted.
> 
> ESC (D nL nH rL rH v h			[Set resolution of raster image]
> nL=04H, nH=00H
> 0<=v<=127
> 0<=h<=127
> vertical resolution is v/(rH*256+rL) inch
> horizontal resolution is h/(rH*256+rL) inch
> available resolutions are (depending on model):
> 	1/120, 1/180, 1/360, 1/720, 1/1440


Karl Heinz

[Gimp-print-devel] The Truth Behind ESC ( D

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

I just received this information from EPSON regarding the ESC ( D
command: 

> 
> The ESC (D command is supposed to be "secret".  That is, we cannot
release
> information on it without a Non-Disclosure Agreement.  However, by
looking
> at a description of the command, I cannot justify withholding it. 
It
> doesn't make sense to me that knowing how to use this command will
allow the
> public in on a trade secret of any kind.  If anything, it will allow
us to
> capitalize on the talents of the Linux community to develop better
drivers
> for us.  Our liaison from Japanese HQ agrees with me.  So here is
the info
> you wanted.
> 
> ESC (D nL nH rL rH v h			[Set resolution of raster image]
> nL=04H, nH=00H
> 0<=v<=127
> 0<=h<=127
> vertical resolution is v/(rH*256+rL) inch
> horizontal resolution is h/(rH*256+rL) inch
> available resolutions are (depending on model):
> 	1/120, 1/180, 1/360, 1/720, 1/1440


Karl Heinz

Re: [Gimp-print-devel] Performance

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

> I did a round of performance tuning tonight.  Essentially, I got rid
> of all but a very few uses of long long; the performance improvement
> is about 40%.

Hmm, I'm surprised it made that much of a difference.

Anyway, from a performance point of view, wouldn't it have made more sense
to go from long long to just plain long, rather than int?

For i386, long and int are equivalent, but, on systems with 64 bit CPU's,
long is equivalent to long long, but, these are precisely the same CPU's
that won't take the same performance hits for using long long that the
i386's do.

Eric

Re: [Gimp-print-devel] Performance

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

Robert L Krawitz wrote:
> 
> I did a round of performance tuning tonight.  Essentially, I got rid
> of all but a very few uses of long long; the performance improvement
> is about 40%.  It's barely possible that this could cause instability
> in extreme cases, although I believe that I checked the code
> reasonably carefully.  If there is instability, it would be in
> extremely dark regions at very high density.
> 
> Obviously, this needs to be tested very thoroughly by a lot of people.
> 

Dithering still seems to be working OK.

However, any attempt to print RGB or RGBA images in mono now results
in the plugin dying with seg faults. I backed out the changes
to print-util.c back to 1.78 and it works (but with the RGBA bug).
I changed the "255" to "2550" and it still works.

Dave

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

[Gimp-print-devel] Performance

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

I did a round of performance tuning tonight.  Essentially, I got rid
of all but a very few uses of long long; the performance improvement
is about 40%.  It's barely possible that this could cause instability
in extreme cases, although I believe that I checked the code
reasonably carefully.  If there is instability, it would be in
extremely dark regions at very high density.

Obviously, this needs to be tested very thoroughly by a lot of people.

I also changed the way the Epson options are set a bit, to cut down on
the volume of code.  Hopefully I haven't broken anyone again...

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

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

I'd like to put out a 3.1.1 sometime around this weekend or so.

-- 
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] [alex@cocoa.demon.co.uk: PATCH:Preliminary BJC4400Photo support for gimp-print]

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

------- Start of forwarded message -------
Date: Tue, 29 Feb 2000 22:02:22 +0000 (GMT)
From: Alex Butcher <al...@co...>
To: rl...@al...
Subject: PATCH:Preliminary BJC4400Photo support for gimp-print

Hi Robert -

This small patch appears to work for the BJC4400Photo. I haven't tested it
thoroughly (only BJ-21e CMYK cartridge, default settings, Plain Paper)
but it seems to work. I have no idea whether /any/ of the settings are
correct. The only print I've done seems quite dark and grainy, but I'm sure
it's all tweakable stuff. The patch is against 3.1.0:

- --- print-canon.c.orig  Tue Feb 29 21:26:25 2000
+++ print-canon.c Tue Feb 29 21:46:09 2000
@@ -262,6 +262,14 @@
     CANON_SLOT_ASF1, 
     CANON_CAP_CMD61 | CANON_CAP_DMT 
   },
+  { /* Canon BJC 4400 */
+    4400,
+    684, 1008, /* 9.5" x 14" */
+    720, 360,
+    CANON_INK_K | CANON_INK_CMYK | CANON_INK_CcMmYK,
+    CANON_SLOT_ASF1,
+    CANON_CAP_CMD61 | CANON_CAP_DMT
+  },
   { /* Canon BJC 6100 */
     6100, 
     11*72, 17*72, 

+++ print-util.c  Tue Feb 29 21:49:35 2000
@@ -1331,6 +1331,8 @@
     canon_parameters,   default_media_size,     canon_imageable_area,
canon_print },
   { "CANON BJC 3000",           "bjc-3000",     1,      3000,   1.0,
0.8,
     canon_parameters,   default_media_size,     canon_imageable_area,
canon_print },
+  { "CANON BJC 4400Photo",           "bjc-4400",     1,      4400,   1.0,
0.8,
+    canon_parameters,   default_media_size,     canon_imageable_area,
canon_print },
   { "CANON BJC 6000",           "bjc-6000",     1,      6000,   1.0,
0.8,
     canon_parameters,   default_media_size,     canon_imageable_area,
canon_print },
   { "CANON BJC 6100",           "bjc-6100",     1,      6100,   1.0,
0.8,

I hope this is of some use.

Best Regards,
Alex.
- -- 
Alex Butcher   Using Linux since '95 - because windows are too easy to break.
Berkshire, UK  URLBLAST:slashdot.org:www.freshmeat.net:www.deja.com:lwn.net:
PGP:0x33489FD3 www.tomshardware.com:www.stardiv.de:www.gimp.org:www.google.com
------- End of forwarded message -------

Re: [Gimp-print-devel] Printing RGB layers in B&W.

[Keith P. <em...@mt...>]

Thanks guys,

You've cracked it.

Much appreciated,

Keith.

   From: Robert L Krawitz <rl...@al...>

      Date: Wed, 01 Mar 2000 12:28:22 +0000
      From: Dave Hill <da...@mi...>
   
      The problem seems to be that after you have merged the layers
      (which you have to do by hand in Gimp 1.0.4), the image is
      "RGB-Alpha". If you just draw on the background, the image is
      "RGB" and works OK. So the problem is in "rgb_to_gray()" which
      isn't handling the alpha channel properly.
   
   OK, I think I know what's wrong here.  I was dividing by the wrong
   constant.  I believe that this happened initially when I was
   converting everything from 8 to 16 bits of precision.  Around 1.74 I
   "fixed" the constant from 25500 to 255, which was incorrect.  I've
   tested this and committed it to the mainline (at first I thought the
   constant was supposed to be 100, but that definitely didn't work :-)
   
   Mitch or Sven, could you apply this to 3.0 when you get

Re: [Gimp-print-devel] Printing RGB layers in B&W.

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

Robert L Krawitz wrote:
> 
> 
> Mitch or Sven, could you apply this to 3.0 when you get
> 
> diff -u -r1.79 print-util.c
> --- print-util.c        2000/02/29 02:59:14     1.79
> +++ print-util.c        2000/03/01 12:47:41
> @@ -809,7 +809,7 @@
>           *gray = vars->lut.composite[((rgb[0] * LUM_RED +
>                                         rgb[1] * LUM_GREEN +
>                                         rgb[2] * LUM_BLUE) *
> -                                      rgb[3] / 255 + 255 - rgb[3])];
> +                                      rgb[3] / 25500 + 255 - rgb[3])];
>           gray ++;
>           rgb += bpp;
>           width --;

Yep, will go to cvs today.

bye,
--Mitch

Re: [Gimp-print-devel] Printing RGB layers in B&W.

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

   Date: Wed, 01 Mar 2000 12:28:22 +0000
   From: Dave Hill <da...@mi...>

   The problem seems to be that after you have merged the layers
   (which you have to do by hand in Gimp 1.0.4), the image is
   "RGB-Alpha". If you just draw on the background, the image is
   "RGB" and works OK. So the problem is in "rgb_to_gray()" which
   isn't handling the alpha channel properly.

OK, I think I know what's wrong here.  I was dividing by the wrong
constant.  I believe that this happened initially when I was
converting everything from 8 to 16 bits of precision.  Around 1.74 I
"fixed" the constant from 25500 to 255, which was incorrect.  I've
tested this and committed it to the mainline (at first I thought the
constant was supposed to be 100, but that definitely didn't work :-)

Mitch or Sven, could you apply this to 3.0 when you get

diff -u -r1.79 print-util.c
--- print-util.c        2000/02/29 02:59:14     1.79
+++ print-util.c        2000/03/01 12:47:41
@@ -809,7 +809,7 @@
          *gray = vars->lut.composite[((rgb[0] * LUM_RED +
                                        rgb[1] * LUM_GREEN +
                                        rgb[2] * LUM_BLUE) *
-                                      rgb[3] / 255 + 255 - rgb[3])];
+                                      rgb[3] / 25500 + 255 - rgb[3])];
          gray ++;
          rgb += bpp;
          width --;

-- 
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] Printing RGB layers in B&W.

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

Keith Parks wrote:
> 
> Hi,
> 
> I have a peculiar problem with the latest CVS versions of the
> print plugin and gimp.
> 
> If I create a new RGB image in Gimp, add a new layer and then
> scribble something on it, when I come to print I get an odd
> behaviour.
> 
> The multi layer is detected and the export/merge-visible dialogue
> activated. I accept this and am presented with the new print
> dialogue.
> 
> My printer is an ancient Apple Laserwriter IINT and my system
> a SPARCstation 5 running Solaris 7.
> 
> I have the Postscript Level 1 options set on both print and file.
> 
> The test image was a white background with a rough fat black
> circle drawn on the top layer.
> 
> If I select b&w and print to a file, the results are not what I
> expect to see. The background is black and the circle inner/outer
> edges just show as dotted white lines.
> 
> If I use colour, the image displays just fine.
> 
> Does anyone else see this or can anyone explain what is happening.
> 
> Thanks,
> Keith.
> 

Yes, I can reproduce this on Gimp 1.0.4 with the latest print
plug in using either Postscript output or PCL output.

The problem seems to be that after you have merged the layers
(which you have to do by hand in Gimp 1.0.4), the image is
"RGB-Alpha". If you just draw on the background, the image is
"RGB" and works OK. So the problem is in "rgb_to_gray()" which
isn't handling the alpha channel properly.

Dave

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

Re: [Gimp-print-devel] Printing RGB layers in B&W.

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

> Single layer RGB and Indexed (multi and single layer) are OK.
> 
> If I merge in Gimp before printing it fails in the same way.
> If I flatten in Gimp before printing the output is OK.

The export routine for the print plug-in assumes that it can handle 
the alpha channel properly. I just reviewed the code in print.c that
calls gimp_export() and it looks fine. So it seems something is
broken with respect to the alpha channel handling. 


Salut, Sven

Re: [Gimp-print-devel] Printing RGB layers in B&W.

[Keith P. <em...@mt...>]

   Date: Tue, 29 Feb 2000 19:07:03 -0500
   From: Robert L Krawitz <rl...@al...>
   
      Date: Tue, 29 Feb 2000 21:42:31 +0000 (GMT)
      From: Keith Parks <em...@mt...>
   
      I have a peculiar problem with the latest CVS versions of the
      print plugin and gimp.
   
   Is this the CVS version of the print plugin from the Gimp source
   (3.0.x) or from the gimp-print source (3.1)?

Both the version with Gimp and the standalone exhibited the same
behaviour with RGB layered imaged.

I did a "cvs update" on the gimp yesterday ans rebuilt the Gimp
overnight (That's how long it takes!!).

Now the Gimp version of print just appears to hang with "Printing..."
on the progress bar. When I cancel the Gimp bombs out.
    
      If I create a new RGB image in Gimp, add a new layer and then
      scribble something on it, when I come to print I get an odd
      behaviour.
   
      The multi layer is detected and the export/merge-visible dialogue
      activated. I accept this and am presented with the new print
      dialogue.
   
   Does this happen with a non-layered (but still RGB) image?  If it
   happens only with a layered image, it sounds like the problem is with
   the Gimp.  If it happens with any kind of RGB image (or it varies with
   the kind of image, indexed behaves differently from RGB for example)
   it may be a problem with the plugin.

Single layer RGB and Indexed (multi and single layer) are OK.

If I merge in Gimp before printing it fails in the same way.
If I flatten in Gimp before printing the output is OK.

A layered RGB image, saved as a .png, calls the export routine to
merge the layers and the saved image is OK when viewed in Netscape.
 
   Also, did this just start?

I'm not sure, all my printing of recent times has been of scanned
images, which have all been single layer.

It's odd the image always displays OK even when merged. It only
seems to be the Postscript printed output that's wrong.

Thanks for your interest.

I'll continue to play and see if I can locate the problem.

Keith.