gimp-print-devel

Re: [Gimp-print-devel] Yet another shot at the variable dot size printers

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

   Date: Wed, 16 Feb 2000 20:08:38 -0700
   From: "S. Miller" <sm...@rn...>
   CC: gim...@so...

   Robert L Krawitz wrote:
   > 
   > Could someone please try a 740 or 750 or something with the latest
   > print-escp2?  Thanks.  Please check in addition to the form factor (if
   > it's correct) that the image SIZE is also correct (it's not twice or
   > half the expected size).

   A correction to my earlier post:  Last night's version had a reasonable
   quality print at 360 dpi.  Tonight's is very grainy and excruciatingly
   slow in both dot types.  Unless I was hallucinating last night ;/

OK, I've made yet another try...but I'm thrashing...

Re: [Gimp-print-devel] Yet another shot at the variable dot size printers

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

   Date: Wed, 16 Feb 2000 20:08:38 -0700
   From: "S. Miller" <sm...@rn...>
   CC: gim...@so...

   Robert L Krawitz wrote:
   > 
   > Could someone please try a 740 or 750 or something with the latest
   > print-escp2?  Thanks.  Please check in addition to the form factor (if
   > it's correct) that the image SIZE is also correct (it's not twice or
   > half the expected size).

   A correction to my earlier post:  Last night's version had a reasonable
   quality print at 360 dpi.  Tonight's is very grainy and excruciatingly
   slow in both dot types.  Unless I was hallucinating last night ;/

Nothing should have changed at 360 dpi.

Re: [Gimp-print-devel] Yet another shot at the variable dot size printers

[S. M. <sm...@rn...>]

Robert L Krawitz wrote:
> 
> Could someone please try a 740 or 750 or something with the latest
> print-escp2?  Thanks.  Please check in addition to the form factor (if
> it's correct) that the image SIZE is also correct (it's not twice or
> half the expected size).
> 
A correction to my earlier post:  Last night's version had a reasonable
quality print at 360 dpi.  Tonight's is very grainy and excruciatingly
slow in both dot types.  Unless I was hallucinating last night ;/

Steve


-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------

Re: [Gimp-print-devel] Yet another shot at the variable dot size printers

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

   Date: Wed, 16 Feb 2000 19:44:51 -0700
   From: "S. Miller" <sm...@rn...>

   I just ran my 740 through all the modes.  In 360 dpi, everything works,
   although with variable dot size it is extremely slow.

Variable dot size does anything at all in 360 dpi mode???  That's
interesting, because it's not supposed to.
							  
							  In the 720 and
   1440 modes, variable dot size just starts ejecting paper (720 high
   quality does print a couple of lines of random text before ejecting). 
   In single dot size, all modes work and have the correct size.

Ugh.  I don't understand that at all.

Re: [Gimp-print-devel] Yet another shot at the variable dot size printers

[S. M. <sm...@rn...>]

Robert L Krawitz wrote:
> 
> Could someone please try a 740 or 750 or something with the latest
> print-escp2?  Thanks.  Please check in addition to the form factor (if
> it's correct) that the image SIZE is also correct (it's not twice or
> half the expected size).
> 
> You'll note that the "720 dpi highest quality", "1440x720 dpi highest
> quality", and "1440x720 two-pass" options have gone away.  That's
> because the method I have to use here doubles the number of passes
> used.  I don't have the time or energy right now to explain exactly
> why that's the case; maybe after dinner I will.
> 

I just ran my 740 through all the modes.  In 360 dpi, everything works,
although with variable dot size it is extremely slow.  In the 720 and
1440 modes, variable dot size just starts ejecting paper (720 high
quality does print a couple of lines of random text before ejecting). 
In single dot size, all modes work and have the correct size.  So far,
though, the 360 dpi modes win for best image quality.  The image I used
is a fairly low contrast one of the Grand Canyon, with a couple of
highlight areas and a few shadow areas.  It is a tough one to make look
good, but is a good test of how well a driver does.

Steve

-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------

[Gimp-print-devel] Yet another shot at the variable dot size printers

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

Could someone please try a 740 or 750 or something with the latest
print-escp2?  Thanks.  Please check in addition to the form factor (if
it's correct) that the image SIZE is also correct (it's not twice or
half the expected size).

You'll note that the "720 dpi highest quality", "1440x720 dpi highest
quality", and "1440x720 two-pass" options have gone away.  That's
because the method I have to use here doubles the number of passes
used.  I don't have the time or energy right now to explain exactly
why that's the case; maybe after dinner I will.

Re: [Gimp-print-devel] unprint bugs fixed

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

   Date: Wed, 16 Feb 2000 20:03:46 -0500
   From: Robert L Krawitz <rl...@al...>
   CC: gim...@li...

      From: sh...@al...
      Date: Thu, 17 Feb 2000 02:47:50 +0900

      Ok, so I fixed a few more bugs in unprint.

      This now *should* be able to unprint the pen_gs file.  I say
      "should" because I don't have enough disk space on my laptop at the
      moment to unprint this thing.  The image is about 100"x1" in
      dimension, and, a 720 DPI, that's, uh, a lot.
      720*720*100*3/1024/1024=148MB.  Hmm...  I could probably clear off
      that much space, but, I'm not going to.

   Looks a lot better.

   BTW, I notice that that image file that my friend gave me came out
   twice as tall as it should have (or half as wide, I don't know).  This
   is interesting considering that the print file we're generating for
   the 740 is twice as wide as it should be.  So it looks like our
   understanding of the ESCi command is incorrect somehow.

I took a closer look at the output files my friend sent me.  It looks
like the one printed at 720 dpi advances on average 24 rows per pass,
while the one printed at 1440 dpi advances on average 12 rows per
pass.  So I think that my theory about double spacing (effectively 360
dpi rather than 720 with ESCi) is probably correct.

Hopefully I'll get a chance to try that this evening.  No promises,
but I might have time to do 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] unprint bugs fixed

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

   From: sh...@al...
   Date: Thu, 17 Feb 2000 02:47:50 +0900

   Ok, so I fixed a few more bugs in unprint.

   This now *should* be able to unprint the pen_gs file.  I say
   "should" because I don't have enough disk space on my laptop at the
   moment to unprint this thing.  The image is about 100"x1" in
   dimension, and, a 720 DPI, that's, uh, a lot.
   720*720*100*3/1024/1024=148MB.  Hmm...  I could probably clear off
   that much space, but, I'm not going to.

Looks a lot better.

BTW, I notice that that image file that my friend gave me came out
twice as tall as it should have (or half as wide, I don't know).  This
is interesting considering that the print file we're generating for
the 740 is twice as wide as it should be.  So it looks like our
understanding of the ESCi command is incorrect somehow.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Re: Patch for print plugin

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

   Date: Wed, 16 Feb 2000 20:32:49 +0100 (CET)
   From: regis rampnoux <re...@re...>

   On 15-Feb-00 Robert L Krawitz wrote:

   > That patch AS IS isn't going to work.  On my system (using
   > PrintPro/CUPS), lpstat -d -v prints out in a slightly different
   > format:

   The commands to obtain the list of printer seems to be a real problem.
   May be you can add a tool to write the list of printers (printrc) manualy? 

This is something we're looking at doing.  There are entirely too many
complaints about the present method, and it simply isn't reliable.

   On FreeBSD, with the native spooler I use: (I have yet sent it to rlk for
   3.0.5, this is for 3.0.6) 

This patch does not work for me:

[2(rlk)||{!258}<rlkppp>/home/rlk/bin/setiathome-1.2.i686-pc-linux-gnulibc1-static]
$ lpc status
epson:
        printer is on device 'parallel' speed -1
        queuing is enabled
        printing is enabled
        no entries
        daemon present
epson-big:
        printer is on device 'parallel' speed -1
        queuing is enabled
        printing is enabled
        no entries
        daemon present
foo:
        printer is on device '/tmp/out' speed -1
        queuing is enabled
        printing is enabled
        no entries
        daemon present
null:
        printer is on device '/dev/null' speed -1
        queuing is enabled
        printing is enabled
        no entries
        daemon present
[2(rlk)||{!259}<rlkppp>/home/rlk/bin/setiathome-1.2.i686-pc-linux-gnulibc1-static]
$ lpc status all

   *** print.c.orig        Wed Feb 16 19:58:01 2000
   --- print.c     Wed Feb 16 19:58:27 2000
   ***************
   *** 3195,3201 ****
       plist[0].v.output_type = OUTPUT_COLOR;

     #ifdef LPC_COMMAND
   !   if ((pfile = popen(LPC_COMMAND " status", "r")) != NULL)
       {
	 while (fgets(line, sizeof(line), pfile) != NULL &&
		plist_count < MAX_PLIST)
   --- 3195,3201 ----
       plist[0].v.output_type = OUTPUT_COLOR;

     #ifdef LPC_COMMAND
   !   if ((pfile = popen(LPC_COMMAND " status all", "r")) != NULL)
       {
	 while (fgets(line, sizeof(line), pfile) != NULL &&
		plist_count < MAX_PLIST)

Re: [Gimp-print-devel] aclocal AM_PATH_GIMP

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

   Date: Wed, 16 Feb 2000 21:03:04 +0000
   From: Nicholas Piper <pc...@in...>

   What do I need to upgrade to stop this problem ;

   piamox7:~/projects/gimp-print/print$ aclocal  
   aclocal: configure.in: 12: macro `AM_PATH_GIMP' not found in library

   I presume I have an old library ?

   I build Gimp from source each time though, so I'm not sure I see why
   there should be something else I need as well ?

Installing Gimp *should* install a file named gimp.m4 in
/usr/local/share/aclocal.  Check to see if you have such a file on
your system?

-- 
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] aclocal AM_PATH_GIMP

[Nicholas P. <pc...@in...>]

What do I need to upgrade to stop this problem ;

piamox7:~/projects/gimp-print/print$ aclocal  
aclocal: configure.in: 12: macro `AM_PATH_GIMP' not found in library

I presume I have an old library ?

I build Gimp from source each time though, so I'm not sure I see why
there should be something else I need as well ?

Nick.

-- 
<pc...@in...>           <http://www.innotts.co.uk/~nicholas/>
2048/BEC44395 1999/08/02 Nicholas C. Piper <nic...@in...>
If you want to change the automatic PGP actions of my mailer, see;
http://www.innotts.co.uk/~nicholas/Personal/personal.php3?page=pgp

RE: [Gimp-print-devel] Re: Patch for print plugin

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

On 15-Feb-00 Robert L Krawitz wrote:

> That patch AS IS isn't going to work.  On my system (using
> PrintPro/CUPS), lpstat -d -v prints out in a slightly different
> format:

The commands to obtain the list of printer seems to be a real problem.
May be you can add a tool to write the list of printers (printrc) manualy? 

On FreeBSD, with the native spooler I use: (I have yet sent it to rlk for
3.0.5, this is for 3.0.6) 

*** print.c.orig        Wed Feb 16 19:58:01 2000
--- print.c     Wed Feb 16 19:58:27 2000
***************
*** 3195,3201 ****
    plist[0].v.output_type = OUTPUT_COLOR;

  #ifdef LPC_COMMAND
!   if ((pfile = popen(LPC_COMMAND " status", "r")) != NULL)
    {
      while (fgets(line, sizeof(line), pfile) != NULL &&
             plist_count < MAX_PLIST)
--- 3195,3201 ----
    plist[0].v.output_type = OUTPUT_COLOR;

  #ifdef LPC_COMMAND
!   if ((pfile = popen(LPC_COMMAND " status all", "r")) != NULL)
    {
      while (fgets(line, sizeof(line), pfile) != NULL &&
             plist_count < MAX_PLIST)




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

[Gimp-print-devel] unprint bugs fixed

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

Ok, so I fixed a few more bugs in unprint.

This now *should* be able to unprint the pen_gs file.  I say "should" because
I don't have enough disk space on my laptop at the moment to unprint this
thing.  The image is about 100"x1" in dimension, and, a 720 DPI, that's,
uh, a lot.  720*720*100*3/1024/1024=148MB.  Hmm...  I could probably
clear off that much space, but, I'm not going to.

Of course, most of that is white space.  Part of the image is printed
near the left edge, part by the right.  The file is royally screwed up.

The vertical bars I was seeing in the windows output are now gone, too.
Same bug.

Eric

Re: [Gimp-print-devel] release? and how to contact printer companies

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

This file you generated has some pretty screwed up commands in it.  The
relative horizontal motion commands are pretty badly garbled.  For
instance:

00001366  1b  (  \ 04 00 a0 05 01 00 *00 *00 

AKA 'Move print head right 93"'  followed by two random 0's.

A normal printer would just ignore this, because it extends beyond where
the paper sensor says there's paper.  unprint doesn't have a paper sensor.
It has nearly infinitely wide paper, so, it should unprint anything you
tell it.  Even nonsensical stuff like this.  There seems to be a bug, though...

Eric

Re: [Gimp-print-devel] release? and how to contact printer companies

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

sh...@al... said: 
[ ... ]
> 
> Well, one of the major problems seems to be a lack of a terminating
> "break;" in the case for the ESC r command.

.. now you lost me. Isn't ESC r the "Select Print color" command.
I don't have the spec here with me, so this is from memory. This
command does not need any "break;". ESC r should take one argument,
which identifies the print color (bmcy -> 0124).

Karl Heinz

Re: [Gimp-print-devel] release? and how to contact printer companies

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

sh...@al... said: 
[ ... ]
> 
> Well, one of the major problems seems to be a lack of a terminating
> "break;" in the case for the ESC r command.

.. now you lost me. Isn't ESC r the "Select Print color" command.
I don't have the spec here with me, so this is from memory. This
command does not need any "break;". ESC r should take one argument,
which identifies the print color (bmcy -> 0124).

Karl Heinz

Re: [Gimp-print-devel] release? and how to contact printer companies

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

sh...@al... said: 

> > This reminds me that I still owe you a GhostScript output file.
> > I've created one and uploaded it on my web site:
> > http://home.rochester.rr.com/specht/test
> 
> Ew. This doesn't unprint cleanly at all...


I noticed :-) I think the problem is in the image size or the
image location:

Image from (2147483647,8020) to (0,8019).

The start position is definitely wrong.

Karl Heinz

Re: [Gimp-print-devel] release? and how to contact printer companies

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

> I noticed :-) I think the problem is in the image size or the
> image location:
> 
> Image from (2147483647,8020) to (0,8019).
> 
> The start position is definitely wrong.

This is normal for the case of no data.  The left edge defaults to MAX_INT
and the right edge defaults to 0.  The raster data is then scanned to look
for pixels to the left of the left edge or to the right of the right edge,
and then the edges are reassigned.

This is done to avoid printing an 8.5" x 11" or A4 or whatever size ppm
every time.  Only the printed region is converted to ppm.

If there is no raster data, then you get the above.  Now I just have to
figure out why it ignored all of the raster data.

Eric

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

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

   From: sh...@al...
   Date: Wed, 16 Feb 2000 16:32:26 +0900

   Scratch that.  It is a family photo, but the resolution isn't that low.
   There was a bug in unprint that was causing pixels to be put in slightly
   the wrong place, resulting in what appeared to be large scale pixelization.

He used a fairly new digital camera for this.

   With the current unprint, it unprints rather well.  Yet, I'm at a loss to
   explain the two vertical bars that appear on the image.

Interestingly enough, it looks half as wide as it should be.  I say
"interesting" because of Karl's experience of getting something that's
TWICE as wide as it should be.  So that suggests that our model of how
the printer works is wrong.

   If you run this through unprint -u, to unweave the softweaving you can see
   the origin of these features more clearly.  On some passes, there is a
   single pixel wide vertical bar.  The position of the bar is not the same in
   each pass, resulting in a multi-pixel wide vertical bar when the data is
   woven.

   I don't know if this is a bug in unprint, or due to some undocumented
   command effect that I haven't taken into account.  Anyone have any ideas?

I was going to wonder if it was a problem with the image, but that
doesn't look likely considering that that line appears in places where
there should be no ink at all.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] release? and how to contact printer companies

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

sh...@al... said: 

> > This reminds me that I still owe you a GhostScript output file.
> > I've created one and uploaded it on my web site:
> > http://home.rochester.rr.com/specht/test
> 
> Ew. This doesn't unprint cleanly at all...


I noticed :-) I think the problem is in the image size or the
image location:

Image from (2147483647,8020) to (0,8019).

The start position is definitely wrong.

Karl Heinz

Re: [Gimp-print-devel] release? and how to contact printer companies

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

> This reminds me that I still owe you a GhostScript output file.
> I've created one and uploaded it on my web site:
> http://home.rochester.rr.com/specht/test

Ew. This doesn't unprint cleanly at all...

Eric

Re: [Gimp-print-devel] release? and how to contact printer companies

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

Robert L Krawitz <rl...@al...> said: 
[ ... ]
> 
> In any event, the Ghostscript Uniprint driver also does softweaving,
> so we're not the first to do so.

This reminds me that I still owe you a GhostScript output file.
I've created one and uploaded it on my web site:
http://home.rochester.rr.com/specht/test

I have no idea if I've used the uniprint driver correctly. This
was actually the first time I used it in command line mode at all.
If you need a different image/different parameters, just let me
know and I'll try to come up with a better/different image.

Karl Heinz

Re: [Gimp-print-devel] release? and how to contact printer companies

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

>    > What reverse engineered code?
> 
>    The windows software.  We're reverse engineering it by way of examining it
> s
>    output.
> 
> We're not reverse engineering the Windows software.  We're reverse
> engineering the command set of the printer for purposes of
> interoperability.

Don't get me wrong.  I'm just playing the Devil's advocate here.  Epson's
lawyers could argue that we are reverse engineering their code, and, I
think that that arguement is strong enough to bring the case to trial,
although, I think, as in the case you mentioned, they would eventually
lose if we defended ourselves.

However, since we are not the ones using the Windows code, we would not
be the defendents.  We are clear on that count.  It's the other people
who generate the files and send them to us who are (arguably) violating
copyright.

> The UCITA bill there isn't law (unless it has actually been signed),

Technically, you are correct, it went through the house, not yet the
senate.  But, it's just a matter of time before it is law there.  I
fully expect the legislature the sign that bill into law.  The courts
will throw it out later after an expensive legal battle.

> and in any event it isn't the law in Massachusetts (where I live).

Nor NY, where I live, and I have *no* idea what the laws are like where
I currently am, in Japan.

> Epson would have to claim copyright on the driver output, which seems
> a bit of a stretch given that it's simply a mechanical translation of
> another work.

No, I don't think they would.  It's all about intent.  If someone
intentionally prints something to give to us, knowing that we're going to
disassemble it, that's a license violation.

> I haven't read what Epson claims to be their license agreement, and I
> don't intend to either because I'm not using their driver software.

I have read it.  It's a fairly standard EULA.

> There was a case recently (Sony against Connectix)

Yeah, I'm familiar with it.  I think we have the moral high ground here,
and what we're doing is not only justified and ethical, but legal, as
well.  That doesn't mean Epson couldn't sue and bring this thing to
trial.

But, even if they could, and even if they could win, I really don't expect
that they would file suit in the first place.  They would have a hell of a
hard time demonstrating damages, and the backlash to their public image
would be noticable.  I don't fear retaliation from Epson for what we're doing.

Eric

Re: [Gimp-print-devel] release? and how to contact printer companies

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

   From: sh...@al...
   Date: Wed, 16 Feb 2000 21:20:42 +0900

   >    Maybe the marketing people are really better concerning strategic
   >    decissions and we should concentrate on them. Perhaps we should
   >    start with designing a note to send to them? But what about the
   >    already reverse engineered code? Any legal problems to be expected?
   > 
   > What reverse engineered code?

   The windows software.  We're reverse engineering it by way of examining its
   output.

We're not reverse engineering the Windows software.  We're reverse
engineering the command set of the printer for purposes of
interoperability.

   As long as we don't generate the files ourselves, it's not our problem.
   The people who gave them to us, if they knew what we intended to do with
   them, could be hit with copyright violation charges.  At least in Virginia.

The UCITA bill there isn't law (unless it has actually been signed),
and in any event it isn't the law in Massachusetts (where I live).
Epson would have to claim copyright on the driver output, which seems
a bit of a stretch given that it's simply a mechanical translation of
another work.

I haven't read what Epson claims to be their license agreement, and I
don't intend to either because I'm not using their driver software.

There was a case recently (Sony against Connectix) where an appeals
court directed a district court to find in favor of Connectix, who
had engaged in much more direct reverse engineering of the CODE (not
merely the operation) of the Playstation.  If Connectix can be found
to have a right to disassemble the code itself (creating intermediate
copies of the actual copyrighted work), I'd think it very hard to
claim that we don't have a right to use the output as we wish (at
least for myself, since I don't have any possible contractual
agreement with Epson -- remember, I have not attempted to install
their software!)  See
http://www.ce9.uscourts.gov/web/newopinions.nsf/f606ac175e010d64882566eb00658118/06d1e0893fdee11688256881006296b8?OpenDocument
for the text of that decision.

In any event, the Ghostscript Uniprint driver also does softweaving,
so we're not the first to do so.

I feel safe enough here (and the large majority, if not the entirety,
of the new Epson code is mine) so that I'm not interested in
contacting a lawyer myself, but if it's something people are concerned
about, they should do 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

Re: [Gimp-print-devel] release? and how to contact printer companies

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

>    Maybe the marketing people are really better concerning strategic
>    decissions and we should concentrate on them. Perhaps we should
>    start with designing a note to send to them? But what about the
>    already reverse engineered code? Any legal problems to be expected?
> 
> What reverse engineered code?

The windows software.  We're reverse engineering it by way of examining its
output.

As long as we don't generate the files ourselves, it's not our problem.
The people who gave them to us, if they knew what we intended to do with
them, could be hit with copyright violation charges.  At least in Virginia.

Eric