gimp-print-devel

Re: [Gimp-print-devel] Tests with Stylus 640

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

   From: sh...@al...
   Date: Mon, 14 Feb 2000 21:37:33 +0900

   > That`s this "remote mode" thing that I`ve never found any
   > documentation for.

   Well, the 750 docs do mention it in passing on page 20 of the Level
   1 docs.  It says it's used for setting the paper feed sequence.
   It's also got a footnote which includes "See the Remote mode
   section for more information".  Unfortunately there is no Remote
   mode section.

I think that's in the NDA stuff.  The other manuals basically say the
same thing about 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] Tests with Stylus 640

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

> That`s this "remote mode" thing that I`ve never found any documentation for.

Well, the 750 docs do mention it in passing on page 20 of the Level 1 docs.
It says it's used for setting the paper feed sequence.  It's also got a
footnote which includes "See the Remote mode section for more information".
Unfortunately there is no Remote mode section.

The only really technical info there is that it starts with ESC ( R and
continues until ESC 0.  The two allowed remote mode commands that it mentions,
SN and ST, are not documented.  It's mentioned again on pages 24 and 25
when it discusses using roll paper in the 1200, but there's no meat to
any of this.

Eric

Re: [Gimp-print-devel] Tests with Stylus 640

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

   From: sh...@al...
   Date: Mon, 14 Feb 2000 20:26:56 +0900

   > BTW, I put an image on http://www.tiac.net/users/rlk/Graphic2.prn that
   > is a Photo 750 output from Windows.  Unprint currently gives a lot of
   > errors.

   I grabbed the file and tried it just a few minutes ago.  I don't get as
   many errors as you did.  And it produces obviously buggy, but recognizable
   output.  You probably ran it through an obsolete unprinter.

That was before the ESCi bug fix.

   Of the less serious errors, the most interesting ones I get are:

   Warning: Unknown command ESC 0x1.        Secret init string?
   Warning: Unknown command ESC ( 0x52.     ESC ( R?
That's this "remote mode" thing that I've never found any
documentation for.
   Warning: Unknown command ESC 0x0.        The null command?
   Warning: Unknown command ESC ( 0x44.     ESC ( D?
THIS is the magic command that I don't understand.  Karl, when you
have a chance, could you try commenting it out and see if it still
prints or not?

   All of these occure while parsing the header.  Once the raster data
   starts coming there are no more errors.

   It may be time to send another message to /dev/nu^H^H^H^H^H^H^HEpson
   techincal support and see if they are willing to comment on this.
   I think I'll go do that.

Good luck (I haven't had any!)

-- 
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] Tests with Stylus 640

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

> BTW, I put an image on http://www.tiac.net/users/rlk/Graphic2.prn that
> is a Photo 750 output from Windows.  Unprint currently gives a lot of
> errors.

I grabbed the file and tried it just a few minutes ago.  I don't get as
many errors as you did.  And it produces obviously buggy, but recognizable
output.  You probably ran it through an obsolete unprinter.

> I don`t actually know what the image is supposed to be, believe it or
> not :-)

You mean you didn't intentially post kiddie porn on your website?  ;)

Actually it appears to be a rather low resolution family photo.

I'm not quite sure what to make of the remaining errors.  The most serious
error you saw was:

             Error decoding RLE data.
             Total bufsize 650, expected 624

When this is encountered, unprint decides it's beaten and just ignores the
whole rest of the file since problems reading compressed data are really
hard to recover from.  There was a bug in the RLE decompression code that
I fixed quite a while ago.  That's probably what accounted for this.
In any case, I can't reproduce that error now.

Of the less serious errors, the most interesting ones I get are:

Warning: Unknown command ESC 0x1.        Secret init string?
Warning: Unknown command ESC ( 0x52.     ESC ( R?
Warning: Unknown command ESC 0x0.        The null command?
Warning: Unknown command ESC ( 0x44.     ESC ( D?

All of these occure while parsing the header.  Once the raster data
starts coming there are no more errors.

It may be time to send another message to /dev/nu^H^H^H^H^H^H^HEpson
techincal support and see if they are willing to comment on this.
I think I'll go do that.

Eric

RE: [Gimp-print-devel] stc740: Partial success

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

> I have a suspicion about what else is going on (besides the row spacing) --
> I have a vague idea (because of the extra width of these prints) that the
> column spacing is something other than 1/720" (specifically, 1/360").  If
> this is the case, we have to treat the 740 and friends as a 360 dpi printer
> to get 720 dpi the same way we get 1440 dpi out of a 720 dpi printer.

I don't think this is the case.  The Ghostscript uniprint driver for the
740 seems to write 720 DPI directly without any funny business.

If anyone doesn't have these files, you can get them here:

http://lcewww.et.tudelft.nl/~haver/linux/epson.html

We could probably use a page of useful links on the gimp-print website.

Eric

[Gimp-print-devel] configure stuff

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

OK, I think I've figured out how to handle Gimp 1.0.  If anyone has
this installed, please give it a try.  It should work to merely

aclocal;autoconf;automake

followed by

./configure
make
make install

identically to Gimp 1.0.

If this all works, I'd REALLY like to do a 3.1.0 (developer) release
soon, so that the Gimp 1.0 folks can get off the ground.  Right now it
eats excessive memory (although it doesn't actually seem to leak), but
that will get fixed fairly shortly.  That aside, how would people feel
about doing a release this week, even though the new Epson printers
don't work?  Is there any update on the PCL driver?  What about the
Canon driver?

It would also be neat if someone else feels like trying the
Ghostscript driver.  As I said last night (to the gimp-print-devel
list, at any rate), the Ghostscript driver does actually seem to work,
although it's extremely slow.  It doesn't seem to be particularly hard
to install from the directions (no harder than I'd expect any other
Ghostscript driver to be).  For now, to create the full Ghostscript
driver, you must

make ghost

after running configure (when we do a release, that won't be
necessary; the make dist that builds the release tarball will take
care of that).  That will populate the Ghost subdirectory with
everything you need.

I might try building it into Ghostscript 6.0, although that can't be
distributed due to license conflict (note that I am *not* the original
author of the print plugin, so I can't relicense it, and to tell the
truth I'd rather keep it GPL'ed myself).

We're woefully short on documentation in here.  Anybody feel like
taking a crack at 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

[Gimp-print-devel] configure stuff

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

I fixed up the configure stuff as follows:

1) make install/uninstlal now does the right thing (uses gimptool
   --install-admin-bin/--uninstall-admin-bin to do its thing).

2) make dist now creates a complete distribution, including the
   Ghostscript stuff.

So the mechanics are now in place for us to do a release when desired,
modulo the issue of Gimp 1.0.  I think I know how to do that, too...

Re: [Gimp-print-devel] stc740: Partial success

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

   Date: Sun, 13 Feb 2000 17:31:11 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   The image is sharper than the results from yesterday, but still
   about twice the width than it should be.

Hmm...there are some other strange artifacts...I have to admit, I'm
really puzzled by those weird vertical bars, too...

   I really appreciate the time you are putting in to fix this
   stuff. ... and I'm really sorry that the turnaround times are so
   long right now, but my wife is in the hospital, and there are just
   more important things to do than to hack on some software project
   ...

There are more important things in the world than software.  Best
wishes for a speedy recovery to your wife.

-- 
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] stc740: Partial success

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

On Sun, Feb 13, 2000 at 12:38:37PM -0500, Robert L Krawitz wrote:
> I have a suspicion about what else is going on (besides the row
> spacing) -- I have a vague idea (because of the extra width of these
> prints) that the column spacing is something other than 1/720"
> (specifically, 1/360").  If this is the case, we have to treat the 740
> and friends as a 360 dpi printer to get 720 dpi the same way we get
> 1440 dpi out of a 720 dpi printer.
>=20
> I've checked in some code to allow this to be tested.  It won't work
> perfectly correctly (the softweave code still assumes 720 dpi column
> spacing), but it may be enough to allow testing this hypothesis.
>=20
> The way to test it is to change the MODEL_MAKE_XRES feature from 720
> to 360 for the printer in question (the 740, but we can try this with
> other printers too).
>=20
> Karl, could give this a try (both with the 720 default value, and if
> that results in something that's too wide, with 360)?

I've tested both versions, and the output looks pretty similar. You can
see for yourself again: http://home.rochester.rr.com/specht/test

The image is sharper than the results from yesterday, but still about
twice the width than it should be.

I really appreciate the time you are putting in to fix this stuff. ... and =
I'm
really sorry that the turnaround times are so long right now, but my wife is
in the hospital, and there are just more important things to do than to hack
on some software project ...=20

Karl Heinz

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

Re: [Gimp-print-devel] stc740: Partial success

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

   Date: Sat, 12 Feb 2000 11:34:35 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   I just a few minutes free time to test the latest version of
   the plugin with my stc740. It now actually puts ink on the paper
   roughly where it belongs :-)

   I've scanned the results and put them up at=20
   http://home.rochester.rr.com/specht/test

I have a suspicion about what else is going on (besides the row
spacing) -- I have a vague idea (because of the extra width of these
prints) that the column spacing is something other than 1/720"
(specifically, 1/360").  If this is the case, we have to treat the 740
and friends as a 360 dpi printer to get 720 dpi the same way we get
1440 dpi out of a 720 dpi printer.

I've checked in some code to allow this to be tested.  It won't work
perfectly correctly (the softweave code still assumes 720 dpi column
spacing), but it may be enough to allow testing this hypothesis.

The way to test it is to change the MODEL_MAKE_XRES feature from 720
to 360 for the printer in question (the 740, but we can try this with
other printers too).

Karl, could give this a try (both with the 720 default value, and if
that results in something that's too wide, with 360)?

[Gimp-print-devel] [neumanns@uni-duesseldorf.de: Re: resend]

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

I botched the previous message; here's Sven's comment.  So I guess if
we want anything of this sort we get to do it ourselves...

------- Start of forwarded message -------
To: Robert L Krawitz <rl...@al...>
cc: gim...@sc...
From: Sven Neumann <neu...@un...>
Subject: Re: resend
In-reply-to: Your message of "Sun, 13 Feb 2000 10:06:24 EST." <200...@ti...>
Date: Sun, 13 Feb 2000 18:17:51 +0100

Hi,

> 
> So one thing that springs to mind here is if the Gimp itself were to
> warn if you attempt to exit while a plug-in is in progress of
> execution.  Gimp folks, would that be feasible?  That would seem
> useful for other long-running things (and some of the filters take a
> long time to run).
> 

If it was that easy, we'd have implememted it long ago. There's no such 
thing as image-locking in The GIMP yet and I fear it won't just show up
before 1.2.


Salut, Sven
------- End of forwarded message -------

Re: [Gimp-print-devel] softweave confusion

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

   From: sh...@al...
   Date: Mon, 14 Feb 2000 00:24:59 +0900

   > I assumed they were spaced 8 rows apart, but the stuff yesterday with
   > the 740 convinced me that they`re 6 rows apart.

   I could've told you that, too.  You can see it clearly in the ghostscript
   uniprint stc740*.upp files.

Ah.  I've been wondering where to get that information.  Thanks for
the pointer.

-- 
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] softweave confusion

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

Never mind.  I find the bug.  Mine, of course.  I'll have a softweave
capable unprint in CVS in a few minutes.

Eric

RE: [Gimp-print-devel] softweave confusion

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

> OK.  This stuff is fairly complicated.  I`ll explain very quickly, and
> then point you to print-escp2.c which has it all explained in a long
> block comment.

Oh, I've read the comment already, of course.  I wouldn't post without
at least having skimmed the code and a comment that long is pretty hard to
miss.

> The most important is that the nozzles in the print head are
> actually separated by more than one row spacing (1/720").

Knew that, too.  It would be an incredible feat of engineering to get them
spaced that closely.  I think it's pretty incredible as it is, with only
1/6th that density.

> I assumed they were spaced 8 rows apart, but the stuff yesterday with
> the 740 convinced me that they`re 6 rows apart.

I could've told you that, too.  You can see it clearly in the ghostscript
uniprint stc740*.upp files.


The thing is that I just can't quite get unprint to unprint the the
softweave correctly.  I'd adjusted the parsing of multi-line raster data
to print every 6th/8th row, and that, AFAICT, is really all that's needed
for unprint to understand softweave data, but, it comes out such that
1/6th of the lines are printed to 6 times and 5/6ths not at all.  (not quite,
but almost)  It seemed like something was off somewhere in the head motion.

I don't know.  I guess I'll just try playing with it some more and try
printing as the EX or one of the other older models.

Eric

Re: [Gimp-print-devel] Tests with Stylus 640

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

   From: sh...@al...
   Date: Sun, 13 Feb 2000 18:08:26 +0900

   > Well, the unprinter doesn`t handle softweave, unfortunately.

   I still don't fully grok how softweave is expressed in ESCP2.  I'll try to
   look into this more.  I haven't tested this much.

Be prepared for a lot of effort and frustration.  It's not terribly
enjoyable...

   So, with ESC i you cannot transfer arbitrary numbers of pixels?

No, although you can always leave some pixels at the end of a row
zeroed out, so you can effectively do this.

Re: [Gimp-print-devel] Can Stylus print closer than 23mm to top of page?

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

   Date: Sun, 13 Feb 2000 17:40:06 +0800
   From: Nick Urbanik <ni...@vt...>

   I find that when printing A4 photos, my printer starts printing about
   22mm down from the top of the page, and ejects the photo before it's
   finished (about 15mm before end of page), and wants to continue printing
   the rest of the photo on another page, for about 12mm or so.  This is a
   waste of paper and ink.  Any suggestions on how to persuade my printer
   to start printing closer to the top of the page?

Are you using one of the softweave modes?  There's a known problem
with that; the page edges aren't being calculated correctly.

-- 
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] softweave confusion

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

   From: sh...@al...
   Date: Sun, 13 Feb 2000 22:28:11 +0900

   Ok, I admit it, I really don't understand softweave.  I get the general
   principle, but the details clearly elude me.

   00000782  1b  i 12 01 01 af 00 30 00  (175, 48, 1) *0d 
   000008fb  1b  (  v 04 00 31 00 00 00 

   The 750 has 48 nozzles, so, we send 48 lines of data at once, one for each
   nozzle.  And then we move down 49 rows?  49?  Why 49?  Doesn't that skip a
   row?

OK.  This stuff is fairly complicated.  I'll explain very quickly, and
then point you to print-escp2.c which has it all explained in a long
block comment.

The first part is correct -- we send 48 lines of data at once, one for
each nozzle.  However, there are a couple of other things going on
here.  The most important is that the nozzles in the print head are
actually separated by more than one row spacing (1/720").  On the
Photo EX there are 32 nozzles spaced 8 rows apart.  On the 750 there
are 48 nozzles, there are 48 nozzles.  I assumed they were spaced 8
rows apart, but the stuff yesterday with the 740 convinced me that
they're 6 rows apart.  So there need to be 6 passes printed to fill in
the gaps between printed rows.

The obvious way to do that would be to advance by 1 row for each of
the 6 passes, then advance by (48 * 6 - 5) rows to start a new series.
The problem with that is that it creates a lot of banding (that's
explained in detail in the comment).  So the name of the game is to
ensure that each adjacent row is printed by DIFFERENT nozzles (some
nozzles are slightly bigger or smaller, or the spacing may not be
perfect, or something).

Even doing that carefully (the 720 Softweave mode) results in some
banding.  So what we do is use multiple passes to print each line, by
splitting up the dots and printing only a subset of them (1/2 in high
quality, 1/4 in highest quality) on each pass.  That way two or four
different nozzles are used to print each row, which further reduces
banding.

The 1440 modes are similar; 1440x720 uses two passes, 1440x720 highest
quality uses four passes.

It's pretty hairy stuff.  Read the comment very carefully.  The
function weave_parameters_by_row does all the cool stuff, but it's
almost impossible to understand (even for me, and I wrote the silly
thing).  It isn't perfect; there are some combinations that don't
work, although everything that I know of that's really important to us
(except maybe for the 440) works.

There's a program called weavetest.c that's actually a unit test for
it.  This program is absolutely essential to have any hope of
maintaining this stuff.

-- 
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] Tests with Stylus 640

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

   From: sh...@al...
   Date: Sun, 13 Feb 2000 17:41:53 +0900

   >      Use the unprinter to sanity check the changes you make.  A lot of the
   >      bugs we`ve been finding can be caught that way.
   >
   > That`s a good point (although I haven`t been able to get it to work --
   > it seems to want to eat all of my memory, and considering that I have
   > 256 MB each of RAM and swap that`s quite a lot).

   Really?  I'm working exclusively on my laptop at the moment.  I've
   got 96MB of physical RAM and I think 64 of swap.  I haven't had any
   such problems.

When I retried it later on it worked just fine, without consuming much
RAM.  So I probably had just used a buggy version.  Sorry for the
trouble.

-- 
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] need progress bar?

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

   From: sh...@al...
   Date: Sun, 13 Feb 2000 17:19:23 +0900

   Hmm, my home university seems to have dropped off the face of the net
   for the past 24 hours...  I'm reading the list off the archive.

   > The Gimp puts its own progress bar on the image you`re printing.  Do
   > we really need our own progress bar?

   Yeah, I know about the one that the gimp puts under the image.  It's
   small and very unobtrusive.  It's very easy to miss.  Even though I know
   it's there, I just didn't think to check it.

   I don't know.  I generally hold the opinion that I'm not quite a complete
   idiot, so, when a UI presents something to me and I miss it, then I tend
   to think that something in the UI is lacking.

   The thing that sets the print plug-in apart from most other gimp plugins
   is that it doesn't modify the image at all.  If I'm waiting for a plugin
   that will change my stick figure drawings into a photorealistic image,
   then I can clearly see that the transformation is not finished and there
   is no need for a pop-up window with a progress bar.  The little one under
   the image is perfect.  But for printing, especially to a file, I think
   something a little more obvious is in order.

   <shrug>  I'm not really going to push for this, if there's a general
   consensus against it, but, if we don't do this, is there some way of
   telling the gimp that we're still working in such a way that the gimp
   would throw up an "Are you sure?" box if the user attempts to quit before
   printing is finished?

   It just seems to me that "fire up gimp; load image; print image; quit gimp"
   might be a fairly common thing for Joe user to do, so, this could become
   a FAQ.

So one thing that springs to mind here is if the Gimp itself were to
warn if you attempt to exit while a plug-in is in progress of
execution.  Gimp folks, would that be feasible?  That would seem
useful for other long-running things (and some of the filters take a
long time to run).

-- 
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] softweave confusion

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

Ok, I admit it, I really don't understand softweave.  I get the general
principle, but the details clearly elude me.

00000782  1b  i 12 01 01 af 00 30 00  (175, 48, 1) *0d 
000008fb  1b  (  v 04 00 31 00 00 00 

The 750 has 48 nozzles, so, we send 48 lines of data at once, one for each
nozzle.  And then we move down 49 rows?  49?  Why 49?  Doesn't that skip a
row?

Eric

[Gimp-print-devel] Can Stylus print closer than 23mm to top of page?

[Nick U. <ni...@vt...>]

Dear folks,

I am a very happy camper.  I have plug and play use of my DC290 Kodak
camera using OpenDis and a Perl program I wrote to download photos
simply by plugging in the camera: no touching the computer.  The program
also automatically puts the photos into my web site, with a new
directory for each day!  (If anyone wants the programs I've written to
do this, you are welcome).  The gimp print plugin with gimp 1.1.16
prints photos beautifully on our Epson Stylus 400, using the Epson 600
driver.  But I have one problem printing photos, using any method.

I find that when printing A4 photos, my printer starts printing about
22mm down from the top of the page, and ejects the photo before it's
finished (about 15mm before end of page), and wants to continue printing
the rest of the photo on another page, for about 12mm or so.  This is a
waste of paper and ink.  Any suggestions on how to persuade my printer
to start printing closer to the top of the page?

--
Nick Urbanik, Dept. of Electrical & Communications Engineering
Hong Kong Institute of Vocational Education (Tsing Yi)
email: ni...@vt..., ni...@io...
Tel:   (852) 2436 8660, (825) 2436 8492   Fax: (852) 2436 8643
pgp ID: 7529555D fingerprint: 53 B6 6D 73 52 EE 1F EE EC F8 21 98 45 1C 23 7B

RE: [Gimp-print-devel] Tests with Stylus 640

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

> Well, the unprinter doesn`t handle softweave, unfortunately.

I still don't fully grok how softweave is expressed in ESCP2.  I'll try to
look into this more.  I haven't tested this much.

> I fixed it so that it doesn`t barf, but it doesn`t do the right thing.

Hmm...

cvs diff -r 1.12 -r 1.13 unprint.c shows, among other trivial things:

415c417
<             n=sh;
---
>             n=sh * 8 / currentbpp;

Sorry about that.  I missed that in the docs completely.  ESC . defines
n in terms of dots and ESC i defines n in terms of bytes.  Nasty.

So, with ESC i you cannot transfer arbitrary numbers of pixels?

Eric

RE: [Gimp-print-devel] Tests with Stylus 640

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

>      Use the unprinter to sanity check the changes you make.  A lot of the
>      bugs we`ve been finding can be caught that way.
>
> That`s a good point (although I haven`t been able to get it to work --
> it seems to want to eat all of my memory, and considering that I have
> 256 MB each of RAM and swap that`s quite a lot).

Really?  I'm working exclusively on my laptop at the moment.  I've got
96MB of physical RAM and I think 64 of swap.  I haven't had any such problems.

I wrote it with the intention of trying to be as memory tight as possible,
since, it will require a lot of RAM for large images.  If you're printing
an 8.5"x11" image at 1440x720 DPI with variable dot size, you will need a
few truckloads of bits, but for smaller prints it should work fine.  RAM
usage should scale roughly linearly with printed area.

I can see basically three possibilities:

   1)  You're printing a huge image.
   2)  There's a bug in unprint, causing it to think you're printing
       a huge image.  (possibly even a HUGE image)  (I've fixed several
       such bugs already)
   3)  There's a bug in gimp-print, causing it to produce bad ESCP2, which
       results in a huge image.

Can you post a URL to what you were trying to unprint that caused the memory
shortage?  Either the original or the ESCP2 file.  Actually the latter may
be preferable.

If it's really desirable to unprint very large images, I can recode this
to use even less RAM, but, it would either need to read through the file
at least twice (making it hard to use in a pipe) or have command line
switches that set the dimensions and positions in advance.

Eric

RE: [Gimp-print-devel] need progress bar?

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

Hmm, my home university seems to have dropped off the face of the net
for the past 24 hours...  I'm reading the list off the archive.

> The Gimp puts its own progress bar on the image you`re printing.  Do
> we really need our own progress bar?

Yeah, I know about the one that the gimp puts under the image.  It's
small and very unobtrusive.  It's very easy to miss.  Even though I know
it's there, I just didn't think to check it.

I don't know.  I generally hold the opinion that I'm not quite a complete
idiot, so, when a UI presents something to me and I miss it, then I tend
to think that something in the UI is lacking.

The thing that sets the print plug-in apart from most other gimp plugins
is that it doesn't modify the image at all.  If I'm waiting for a plugin
that will change my stick figure drawings into a photorealistic image,
then I can clearly see that the transformation is not finished and there
is no need for a pop-up window with a progress bar.  The little one under
the image is perfect.  But for printing, especially to a file, I think
something a little more obvious is in order.

<shrug>  I'm not really going to push for this, if there's a general
consensus against it, but, if we don't do this, is there some way of
telling the gimp that we're still working in such a way that the gimp
would throw up an "Are you sure?" box if the user attempts to quit before
printing is finished?

It just seems to me that "fire up gimp; load image; print image; quit gimp"
might be a fairly common thing for Joe user to do, so, this could become
a FAQ.

Eric

[Gimp-print-devel] Ghostscript driver

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

Actually, the performance was even worse: around the middle of the 6th
page Ghostscript died with an error.  So it only printed 5+ pages in
over 16 minutes of CPU time, and generated 20 MB of output.

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