gimp-print-devel

Re: [Gimp-print-devel] Somebody with an Epson 750 or 1200 or 740 or 900, please try!

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

   Date: Sat, 26 Feb 2000 07:14:14 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   Hmmm... I expected a dramatic difference, but the two images I printed
   on the stc740, high quality setting with 72 ppi and default settings=20
   (gamma =3D 1, brightness =3D 100, contrast =3D 100, ...) look not too=20
   different. My impression however is that the new code looks a little=20
   more like the the output I get from the Lexmark Optra Color 40=20
   (PostScript color inkjet).

It would affect midtones and highlights primarily; I swapped the two
bits, so that the codes for levels 1 and 2 were reversed.

   On a different subject: What settings are you using with which printers?
   I think we should collect a list of settings with information about=20
   the paper type used and which printer and print mode to make it easier
   for people to reproduce results.

Paper type?  Whatever I have handy :-)  Right now I'm using coated
matte card stock.

More seriously, you're right.  This is something we should do as much
as we can with for 3.2.

   And on another different subject: Robert, what's the status of the PostScri=
   pt
   driver? I noticed some problems with missing newlines in the PS output for
   the Lexmark in the setpagedevice section. I can take a look this weekend
   if you like.

Could you?  I haven't maintained the PostScript driver (this means
print-ps.c, not the Epson Ghostscript driver).

Speaking of Lexmark, I've been talking with someone who's working on a
Lexmark driver.  He sounds interested in working with us.

-- 
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] Somebody with an Epson 750 or 1200 or 740 or 900, please try!

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

On Fri, Feb 25, 2000 at 08:47:02PM -0500, Robert L Krawitz wrote:
> Staring at the code, I think I found an error in the code that would
> produce rather strange looking output (dark areas would be too light,
> and light areas too dark in some cases -- it would also show up as
> color shifts).  Could somebody please replace escp2_fold in
> print-escp2.c with the version below and tell me which one works
> better (printing in variable dot size mode)?  Thanks.

Hmmm... I expected a dramatic difference, but the two images I printed
on the stc740, high quality setting with 72 ppi and default settings=20
(gamma =3D 1, brightness =3D 100, contrast =3D 100, ...) look not too=20
different. My impression however is that the new code looks a little=20
more like the the output I get from the Lexmark Optra Color 40=20
(PostScript color inkjet).

I wanted to do some more extensive testing with all the possible print
modes later today just to give you another data point regarding the
740 status.

On a different subject: What settings are you using with which printers?
I think we should collect a list of settings with information about=20
the paper type used and which printer and print mode to make it easier
for people to reproduce results.

And on another different subject: Robert, what's the status of the PostScri=
pt
driver? I noticed some problems with missing newlines in the PS output for
the Lexmark in the setpagedevice section. I can take a look this weekend
if you like.

Karl Heinz=20

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

[Gimp-print-devel] Somebody with an Epson 750 or 1200 or 740 or 900, please try!

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

Staring at the code, I think I found an error in the code that would
produce rather strange looking output (dark areas would be too light,
and light areas too dark in some cases -- it would also show up as
color shifts).  Could somebody please replace escp2_fold in
print-escp2.c with the version below and tell me which one works
better (printing in variable dot size mode)?  Thanks.

A good test image is http://www.tiac.net/users/rlk/colors.tif.

static void
escp2_fold(const unsigned char *line,
	   int single_length,
	   unsigned char *outbuf)
{
  int i;
  for (i = 0; i < single_length; i++)
    {
      outbuf[0] =
	((line[0] & (1 << 7)) >> 0) +
	((line[0] & (1 << 6)) >> 1) +
	((line[0] & (1 << 5)) >> 2) +
	((line[0] & (1 << 4)) >> 3) +
	((line[single_length] & (1 << 7)) >> 1) +
	((line[single_length] & (1 << 6)) >> 2) +
	((line[single_length] & (1 << 5)) >> 3) +
	((line[single_length] & (1 << 4)) >> 4);
      outbuf[1] =
	((line[0] & (1 << 3)) << 4) +
	((line[0] & (1 << 2)) << 3) +
	((line[0] & (1 << 1)) << 2) +
	((line[0] & (1 << 0)) << 1) +
	((line[single_length] & (1 << 3)) << 3) +
	((line[single_length] & (1 << 2)) << 2) +
	((line[single_length] & (1 << 1)) << 1) +
	((line[single_length] & (1 << 0)) << 0);
      line++;
      outbuf += 2;
    }
}

-- 
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] How to use special Inks?

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

OK, I've changed dither_black4 and dither_cmyk4 (and renamed them to
dither_black_n and dither_cmyk_n) to take an extra argument
(use_log_encoding) which specifies whether to encode the levels
logarithmically or to use (implied) n different planes, one per
level.  I'm committing this right now.

Re: [Gimp-print-devel] How to use special Inks?

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

   Date: Fri, 25 Feb 2000 23:29:23 +0100 (CET)
   From: regis rampnoux <re...@re...>

   On 25-Feb-00 Robert L Krawitz wrote:

   > So this is black & white?  Very interesting.  The driver doesn't know
   > anything about this kind of stuff.  Wanna start coding :-?

   I had a look to photoshop.  If you convert a grayscale image in
   CMYK you have different layers. There is not only the layer black
   which contains information (unlike "The Gimp"). But the print
   plug-ins seems to convert with his rules and seems to use ink
   values like PS. (Sorry, my english is bad, I apologize for that).

Well, the way to get smooth output is to use as many dots as possible
scattered as evenly as possible.  Using CMY to generate black means
that a lot more dots are needed, which makes things appear much
smoother.

   >  MIS Sixtone Inkset - 15%-LC, 25%-C, 45%-LM, 50%-Y, 75%-M,  100%-K

   I interpret (I hope that it is right) the value as:
   for gray between 0-15% use ink from light cyan  
   for 16-25% from cyan
   for 26-45% from light magenta 
   ... 

More or less true.

   This should be interresting to dithering B&W photographies?
   Do you need inks to try?
   who can/want have a look about this?

I have to admit that this would be a really interesting project and
wouldn't be too hard.  The dither_black4 routine isn't quite right for
this, but it would be very easy to adapt it or create a very similar
routine that would do the right thing here (create N planes of output
rather than a log N bit encoding).  Then it's just a matter of hacking
the Epson driver to know about this, and set up the right dithering
parameters (3.1 does this right).

The problem with it is that it's very specialized; there aren't a
whole lot of people (that I'm aware of) using these inks.  I would be
happy to accept a patch for it, if it's well written or easy to fix up
(if you want to try it, I'll write or adapt the dither routine for
you), but we have more pressing issues to deal with, such as
documentation, improving the GUI, improving performance, and so forth.
As a photographer, being able to generate high quality, archival black
& white images in this fashion would be fascinating, 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] How to use special Inks?

[regis r. <re...@re...>]

On 25-Feb-00 Robert L Krawitz wrote:

> So this is black & white?  Very interesting.  The driver doesn't know
> anything about this kind of stuff.  Wanna start coding :-?

I had a look to photoshop.
If you convert a grayscale image in CMYK you have different layers. There is
not only the layer black which contains information (unlike "The Gimp"). But the
print plug-ins seems to convert with his rules and seems to use ink values like
PS. (Sorry, my english is bad, I apologize for that).

>  MIS Sixtone Inkset - 15%-LC, 25%-C, 45%-LM, 50%-Y, 75%-M,  100%-K

I interpret (I hope that it is right) the value as:
for gray between 0-15% use ink from light cyan  
for 16-25% from cyan
for 26-45% from light magenta 
... 

This should be interresting to dithering B&W photographies?
Do you need inks to try?
who can/want have a look about this?

-- 
<regisr>       re...@re...     http://www.regix.com/

Re: [Gimp-print-devel] How to use special Inks?

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

   Date: Thu, 24 Feb 2000 23:06:51 +0100 (CET)
   From: regis rampnoux <re...@re...>

   >              1.
   >                  MIS Sixtone Inkset - 15%-LC, 25%-C, 45%-LM, 50%-Y, 75%-M,
   100%-K
   > 
   > Whatever this means...

   The cartridge contains gray inks with different values:
   Ligth Cyan = gray 15%
   Cyan = gray 25%
   ...
   How to explain this to the driver?

So this is black & white?  Very interesting.  The driver doesn't know
anything about this kind of stuff.  Wanna start coding :-?

   > You're going to be on your own here; I suggest experimenting and
   > giving us back settings that work well with these inks.  I realize
   > they're expensive, but there's not a lot of choice.

   Yes I known that I must do this but I don't known where I must
   enter the values?  If someone in the development team is interested
   by this I can send cartridges too ;-) For MIS color inks there is
   also problem because they are differents than Epson inks.

I presume that the color inks are the same basic colors, but the
values are a bit different.  If so, it should be easier to handle.

-- 
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] How to use special Inks?

[regis r. <re...@re...>]

On 24-Feb-00 Robert L Krawitz wrote:

>    I have an EX printer (I have buy the same printer than the Master
>    (aka rlk)) (NB for rlk: now prints are Ok with 3.0.6 ... I don't
>    have anymore the previous problem and I can't explain it)
> I suggest upgrading to 3.0.8 or 3.1.0, or 3.0.9 (which should be out
> before the night is done).

Oups, I wanted to say that releases after 3.0.6 are working!
If you remember I had strange print-outs.
Now I use the 3.1.0 of course.

>              1.
>                  MIS Sixtone Inkset - 15%-LC, 25%-C, 45%-LM, 50%-Y, 75%-M,
100%-K
> 
> Whatever this means...

The cartridge contains gray inks with different values:
Ligth Cyan = gray 15%
Cyan = gray 25%
...
How to explain this to the driver?

> You're going to be on your own here; I suggest experimenting and
> giving us back settings that work well with these inks.  I realize
> they're expensive, but there's not a lot of choice.

Yes I known that I must do this but I don't known where I must enter the values?
If someone in the development team is interested by this I can send cartridges
too ;-)
For MIS color inks there is also problem because they are differents than
Epson inks. 


-- 
<regisr>       re...@re...     http://www.regix.com/

[Gimp-print-devel] (no subject)

[Francisco C. <fca...@te...>]

confirm 292196

[Gimp-print-devel] Re: Looking for canon printer driver

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

Anyone want to get in touch with this person?

Louis Paradis <par...@ge...> writes:

> I'm looking for the canon BJC-4100 driver. Any idea where I can find it?
> 
> Thanks
> 
> LP
> 

-- 
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] Have to slow down a bit

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

I'm going to have to slow down a bit with this stuff.  Over the past
month or so (and particularly the past week) I've been putting more
effort into this than I can really sustain.  I'm certainly not going
to pull out of development -- we're getting together some pretty good
stuff here, and it's a lot of fun -- it's just that I'm going to limit
how much I do, and some days I won't do much besides check email a
couple of times a day.

I may spend some time writing up some doc on the weave stuff or
something.

BTW, I took a look at the Stylus 9000 doc.  It has some info on remote
mode!!!  It doesn't sound all that exciting, but it's good stuff to
know.  There's other stuff in there that might be useful.  Beyond
that, it basically sounds like a cross between the 900 and the 1200 on
steroids.  THAT would be a fun printer to support.

-- 
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] Print 3.0.9

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

I put 3.0.9 up on gimp-print.sourceforge.net, and Sven checked the
equivalent into the Gimp proper.

This will be the last standalone release on the 3.0 branch.  The
standalone code is getting too far out of sync with the Gimp CVS
repository to make this very easy, and the real action is happening in
3.1, anyway.

There may still be updates to 3.0, either bug fixes or new features
(probably just new UI stuff; 3.1 has changed fairly extensively
internally, and bringing the new printer stuff back would be too much
effort and too risky).

-- 
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] canon-unprint

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

   Date: Wed, 23 Feb 2000 19:01:43 +0100
   From: Andy Thaller <th...@ph...>

   sh...@al... wrote:

   > > strange... anyway, I've just commit a bugfixed version of print-canon.c that
   > > actually produces valid output and a slightly modified unprint.c
   >
   > I'm on the repository mailing list, so, I see what you commit as soon as
   > you commit it.  Assuming I'm reading my mail that is...

   Ah, how gan I get there? :-)

Is there anyone on here who would *not* like to be on the commit list?
You can add yourself by checking out the CVSROOT module, editing
loginfo, and checking it back in.

-- 
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] How to use special Inks?

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

   Date: Wed, 23 Feb 2000 23:00:33 +0100 (CET)
   From: regis rampnoux <re...@re...>

   I have an EX printer (I have buy the same printer than the Master
   (aka rlk)) (NB for rlk: now prints are Ok with 3.0.6 ... I don't
   have anymore the previous problem and I can't explain it)

BTW, I strongly suggest downloading either 3.0.9 or 3.1.0 from
gimp-print.sourceforge.net.  Both of these releases have important bug
fixes over 3.0.6; for the EX, they are essentially equivalent in
functionality.

-- 
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] How to use special Inks?

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

   Date: Wed, 23 Feb 2000 23:00:33 +0100 (CET)
   From: regis rampnoux <re...@re...>

   How can I use specials Inks?
   For N&B I want to use MIS Inks. How to setup the print plug-in for it?

   See http://www.missupply.com/ for colors and N&B archivals Inks.

You're going to be on your own here; I suggest experimenting and
giving us back settings that work well with these inks.  I realize
they're expensive, but there's not a lot of choice.

   I have an EX printer (I have buy the same printer than the Master
   (aka rlk)) (NB for rlk: now prints are Ok with 3.0.6 ... I don't
   have anymore the previous problem and I can't explain it)

I suggest upgrading to 3.0.8 or 3.1.0, or 3.0.9 (which should be out
before the night is done).

	       1.
		   MIS Sixtone Inkset - 15%-LC, 25%-C, 45%-LM, 50%-Y, 75%-M, 100%-K

Whatever this means...

			 Printer Color Management: OFF 
			 1400 dpi Photo Quality Inkjet Paper Setting
			 Error Diffusion = On 
			 Supermicroweave = On
			 Automatic = On
			 Saturation Slider = -7, all other sliders set at 0 

I would suggest using 1440 dpi Highest Quality; maybe start with
saturation around 0.9 or so and go from there.

-- 
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] How to use special Inks?

[regis r. <re...@re...>]

Hello,

How can I use specials Inks?
For N&B I want to use MIS Inks. How to setup the print plug-in for it?

See http://www.missupply.com/ for colors and N&B archivals Inks.

I have an EX printer (I have buy the same printer than the Master (aka rlk))
(NB for rlk: now prints are Ok with 3.0.6 ... I don't have anymore the previous
problem and I can't explain it)

the procedure for Photoshop:


            Procedure for Epson Stylus Photo 700 and Photo EX printers 

           This procedure is for printing Quadtones on an Epson Photo 700 or
Photo EX printer. Note that it is for coated paper only, like Somerset
Enhanced, Concord Rag or photo glossy paper.

            Note: If you get excessive bleeding or dot gain on Concord Rag, try
drying the paper in a microwave oven. Accumulated moisture or high humidity
will cause bleeding. 
            1.
                MIS Sixtone Inkset - 15%-LC, 25%-C, 45%-LM, 50%-Y, 75%-M, 100%-K
            2.
                Color setup conversion for Photoshop: 

                      CMYK conversion:

                      Click on... File | Color Settings | CMYK set up | Built
in | SWOP coated | 20% dot gain |
                      UCR

                      RGB conversion:

                      Click on...File | Color Settings | RGB Setup | Adobe RGB
or Monitor RGB 

            3. 
                Scan a photograph grayscale or RGB at maximum scanner optical
resolution. 
            4.
                Convert to RGB or CMYK:

                Comment: Perhaps CMYK gives a bit better black, but the file
size is larger.  You will probably need to lighten the image to print
correctly.  We suggest a curves adjustment in Photoshop because it does not
clip image data.  Some prefer an adjustment curve and others prefer to make a
curve and save it and apply it in Page Setup in the Transfer function. The
essence is that the image is probably going to need lightening somehow.
            5. 
                Print Space: Standard Epson Driver 

                      Printer Color Management: OFF 
                      1400 dpi Photo Quality Inkjet Paper Setting
                      Error Diffusion = On 
                      Supermicroweave = On
                      Automatic = On
                      Saturation Slider = -7, all other sliders set at 0 



-- 
<regisr>       re...@re...     http://www.regix.com/

Re: [Gimp-print-devel] canon-unprint

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

sh...@al... wrote:

> > strange... anyway, I've just commit a bugfixed version of print-canon.c that
> > actually produces valid output and a slightly modified unprint.c
>
> I'm on the repository mailing list, so, I see what you commit as soon as
> you commit it.  Assuming I'm reading my mail that is...

Ah, how gan I get there? :-)

> > I've printed to a file using the bjc6000 driver @ 360x360 dpi, postcard, plai
> > n
> > paper, small scaling and was able to deprint it with canon-unprint.cpp which
> > showed me the printer driver works allright now. however, unprint still
> > produces noise only...
>
> Ok, if you can't figure it out shortly, I'll have a look at it tomorrow.
> It's past my bed time for today, though.

So have a good night then.

Andy.

Re: [Gimp-print-devel] canon-unprint

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

sh...@al... wrote:

> Hmm, I wasn't able to get it to unprint at all.  Are there particular
> settings I should use when printing the image to a file?  I choose Canon
> BJC 3000, photo ink, 720 DPI.  When unprint is given the file when
> UNPRINT is set to canon, I get the following:
>
>     Warning: Unknown command ESC [ 0x61 at 0x0000000A.
>     canon: res is 720 x 720 dpi
>
>     K:129->223Y:170->223M:146->223C:145->223Error: unsupported color type 0x00.

Hmm - could be an older version than mine - when did you update?

Andy.

Re: [Gimp-print-devel] canon-unprint

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

> The output produced from canon-printfiles looks extremely poor - there are
> some weird artefacts. Eric, could you please have a look at it? Maybe I've go
> t
> something terribly wrong?

Hmm, I wasn't able to get it to unprint at all.  Are there particular
settings I should use when printing the image to a file?  I choose Canon
BJC 3000, photo ink, 720 DPI.  When unprint is given the file when
UNPRINT is set to canon, I get the following:

    Warning: Unknown command ESC [ 0x61 at 0x0000000A.
    canon: res is 720 x 720 dpi

    K:129->223Y:170->223M:146->223C:145->223Error: unsupported color type 0x00.

BTW, on my 1024x768 LCD, the driver selection box already scrolls off the
bottom of the screen.  Is there anything after Canon BJC 3000?  I can't tell,
I'm out of pixels.  We should probably change the driver selector to be
two pull down menus.  The first menu would be manufacturer, the second would
be a list of models.  That should make the lists a little more manageable.

Eric

Re: [Gimp-print-devel] canon-unprint

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

> * Added parse_canon() with calls to page_update()
> * Added rle_decode() since canon rather knows the compressed buffer size than
> the uncompressed
> * Added switching from parse_escp2() to parse_canon() via environment variabl
> e

I spent about 30 seconds scanning your code.  What I saw looked pretty good.

> UNPRINT:
>    "UNPRINT=canon ./unprint" will use parse_canon()

Ok, although I'd like to remove this feature eventually.

Unfortunately, there's no really simple way to do that.  What we want is
for each routine to be given a file pointer and be able to read that file
from the beginning, yet we need to read some of the file to determine what
the file type is.  There are only two ways to do this that I can think of.
One is to create a pipe internally, fork the process, read the data in
one process, determine the file type, and write the data to the pipe which
then gets read and parsed by the appropriate child process.

The other way is to read to a buffer, and then only read from the file
if the buffer is empty.

I think the second method would require less in the way of computer resources,
although I think the first is stylistically cleaner.

I haven't decided which is the better way to go.

> The output produced from canon-printfiles looks extremely poor - there are
> some weird artefacts. Eric, could you please have a look at it? Maybe I've go
> t
> something terribly wrong?

I just compiled it.  I'll have a look.

Eric

[Gimp-print-devel] canon-unprint

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

Just committed some changes to unprint.c:

* Added parse_canon() with calls to page_update()
* Added rle_decode() since canon rather knows the compressed buffer size than
the uncompressed
* Added switching from parse_escp2() to parse_canon() via environment variable
UNPRINT:
   "UNPRINT=canon ./unprint" will use parse_canon()

The output produced from canon-printfiles looks extremely poor - there are
some weird artefacts. Eric, could you please have a look at it? Maybe I've got
something terribly wrong?

Andy.

Re: [Gimp-print-devel] STC800 problems (was Print plugin 3.0.6 bug report)

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

   Date: Tue, 22 Feb 2000 20:18:25 +0100
   From: "Stefan K. Berg" <sf...@co...>

   Robert L Krawitz wrote:
   >> [snip]
   >> I did, but found 24/1 to be the best looking so far (very small
   >> horizontal stripes) and it looks just right in size compared to the
   >> output in microweave 720. All the other variations has been too
   >> large vertically. Talking strictly proportionally, it would seem
   >> that 24/0 would be a great setting...
   > 
   >  Wow.  What happens in high and highest quality mode, and with 1440?
   >  Is it much faster than microweave?  How is the quality?  It might be
   >  that the 800 can actually do microweave well.

   Well, I haven't tested 1440 yet. I have enough trouble with the
   other modes...

   Faster than microweave? Huh? Every higher mode is slower and slower
   to print - testing 720 DPI highest quality made me go out for
   dinner. :) Can't really judge the quality yet due to the banding
   problems, see below.

Here's my question: is 720 microweave as fast as 720 softweave?  If
so, then there may be no need to support softweave on this printer.

   I've found this out so far, going with the 24/1 setting for now -
   you probably agree that that was the best one of the ones tested:

   Original (new) picture: http://home.swipnet.se/consultron/tulip.jpg

   The three following at http://home.swipnet.se/consultron/tulip1.jpg:

   360 microweave: Banding. Severe banding. Interestingly enough, the
   bands are pink, the same as the tulip in the center of the
   picture. You'll spot this one easy.

Not too surprising.  360 is for proofing only.  We can probably adjust
the droplet size to improve the quality.

   720 microweave: The best looking one. Almost untracable banding.

The magenta has problems, as usual :-(  Try printing with a bit more
saturation?

   Is it possible that this banding might be a problem in the
   algorithms, or should I continue to try different nozzle/separation
   configurations?

If 720 microweave is fast, don't bother -- this will be a
microweave-only printer.  I suspect that the same will be true for all
of the early printers, but I don't have access to a Pro, Pro XL, 400,
500, 600, 850, 1520, or 3000.

Guess it means I'll have to get 1440 microweave working 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

Re: [Gimp-print-devel] STC800 problems (was Print plugin 3.0.6 bug report)

[Stefan K. B. <sf...@co...>]

Robert L Krawitz wrote:
>> [snip]
>> I did, but found 24/1 to be the best looking so far (very small
>> horizontal stripes) and it looks just right in size compared to the
>> output in microweave 720. All the other variations has been too
>> large vertically. Talking strictly proportionally, it would seem
>> that 24/0 would be a great setting...
> 
>  Wow.  What happens in high and highest quality mode, and with 1440?
>  Is it much faster than microweave?  How is the quality?  It might be
>  that the 800 can actually do microweave well.

Well, I haven't tested 1440 yet. I have enough trouble with the other modes...

Faster than microweave? Huh? Every higher mode is slower and slower to print -
testing 720 DPI highest quality made me go out for dinner. :) Can't really
judge the quality yet due to the banding problems, see below.

I've found this out so far, going with the 24/1 setting for now - you probably
agree that that was the best one of the ones tested:

Original (new) picture: http://home.swipnet.se/consultron/tulip.jpg

The three following at http://home.swipnet.se/consultron/tulip1.jpg:

360 microweave: Banding. Severe banding. Interestingly enough, the bands are
pink, the same as the tulip in the center of the picture. You'll spot this one
easy.

720 microweave: The best looking one. Almost untracable banding.

720 softweave:  Banding, pink. On the lower part of the picture, the banding
is less proportional than on the top one. This one was printed at the lowest
possible position (in the GUI) on A4, and was cropped with the last part of the
picture output on the next page.

720 DPI high quality: Wouldn't print! I got a small band of ink, then the
printer started feeding paper. Tried setting the picture in different locations
on the paper, but that didn't matter.

The next one at http://home.swipnet.se/consultron/tulip2.jpg:

720 DPI higest quality: Symmetrical banding. There's a single black band on
the lower half of the picture - don't know if that's a smear or a real problem.
Haven't got time to reprint it right now - it took loooong time.

Is it possible that this banding might be a problem in the algorithms, or should
I continue to try different nozzle/separation configurations?

[Gimp-print-devel] ANNOUNCE: gimp-print 3.1.0

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

This is the first version on the 3.1 (development) series.  It is
available at http://gimp-print.sourceforge.net.  In addition to the
plug-in for the Gimp, the same source base is used as the nucleus of a
GhostScript driver to support Epson Stylus printers.

Gimp developers, should I send these announcements to gimp-developer,
or should individuals simply subscribe to gimp-print-announce?  Also,
any other suggestions about where I should send this announcement?

The release notes follow:


This is the Print plugin for the Gimp, version 3.1.0.  This is a
development release, the first on the 3.1 branch.  If this software
causes your print head to zoom off the end of your printer, spilling
ink all over your 1000 year old Persian rug, don't blame us.
Remember, you installed the software.

This software also comes with a GhostScript driver for Epson Stylus
printers.  The support for Epson Stylus printers in the GhostScript
driver is identical to the support for these printers in the Print
plugin -- they use the identical code base.

This plugin can be compiled against either Gimp 1.1 or 1.0.

Print 3.1.0 contains the following user-visible improvements over
Print 3.0.5, the version distributed with the Gimp 1.1.17:

1) Preliminary support for Canon BubbleJet printers (specifically the
   BJC6000).

2) Preliminary support for the Epson Stylus Color 440/640/740/900 and
   Stylus Photo 750/1200 printers.  These printers should in theory
   work in all modes, although that has not been comprehensively
   tested.  1440 dpi mode on the 900 in particular may not work.
   There is also pre-preliminary support for the Stylus Photo 870 and
   1270 based on the published specifications.  This driver is
   completely untuned for these printers at present.

3) Ability to position the image on the page to the point (1/72", or
   about .35 mm), along with a more accurate depiction of the
   positioning on the page.

4) One-click ability to scale to the image resolution (Gimp 1.1 only).

5) Much better handling of the saved state (printrc file), including
   saving of parameters related to file output.

6) Utilities (in various states of completion) to reconstitute an
   image from a print file.

7) Bug fixes for density in indexed and gray modes, and for excess
   pseudo-black printing in general.

There are additional improvements over Print 2.0.2 (the version
distributed with Gimp 1.1.11 and earlier) too numerous to list here.

-- 
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] Print plugin 3.0.6 bug report

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

   Date: Mon, 21 Feb 2000 20:47:49 +0100
   From: "Stefan K. Berg" <sf...@co...>
   CC: gim...@li...

   Robert L Krawitz wrote:
   > 
   >    Date: Mon, 21 Feb 2000 10:00:11 +0100 From: "Stefan K. Berg"
   >    <sf...@co...> CC:
   >    gim...@li...
   > 
   >    Robert L Krawitz wrote:
   > 
   >    > Really.  That's very interesting.  Remind me again what you
   >    > have -- it's an 800, right?  In a way, this is good news;
   >    > the only issue is whether some printers need the 5 and some
   >    > need the 40.
   > 
   >    Yes, an 800.
   > 
   > Are you still having trouble printing in microweave?

   I just did a test with my previously black test picture, and the
   answer is no!  It looks fine.

OK, so I think I have that one nailed too.  Other people had problems
with indexed images, too.  It wasn't entirely a problem with indexed
images; it was a combination of a bug with indexed images (ignoring
the density setting) and the dither routine (in very dark regions it
was unstable).

   I did, but found 24/1 to be the best looking so far (very small
   horizontal stripes) and it looks just right in size compared to the
   output in microweave 720. All the other variations has been too
   large vertically. Talking strictly proportionally, it would seem
   that 24/0 would be a great setting...

Wow.  What happens in high and highest quality mode, and with 1440?
Is it much faster than microweave?  How is the quality?  It might be
that the 800 can actually do microweave well.

   Pictures as always on http://home.swipnet.se/consultron/test4.jpg
   (87 kB). The microweave version is the one at the bottom to the
   right.

   I will use a better (non-indexed) test picture from 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