gimp-print-devel

Re: [Gimp-print-devel] Another unknown...

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

   From: sh...@al...
   Date: Sun, 06 Feb 2000 23:34:39 +0900

   Ok, my printer simulator is coming along.  I'm going to commit some large
   improvements later tonight.  It's still spitting this error, among others:

   Warning: Unknown command ESC 0x8.

8, or 6?  My tool doesn't show any ESC 0x8, but I do see ESC 0x6 when
I use the 750 driver (or anything else).  To tell the truth, I don't
remember why that's in there.

Re: [Gimp-print-devel] building with autoconf

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

> On Sun, 06 Feb 2000, sh...@al... wrote:
> 
> > > I'm probably missing something, but isn't the current
> > > build mechanism to run "autoconf" and then "./configure" ?
> 
> > You need to run "aclocal" before autoconf.
> 
> Ok, works better now. Still not complete though, as ./configure
> can't find Makefile.in. I might have deleted that, but it isn't
> in the CVS so I guess it's not taken from there...

You need to run "automake" before configure.

Aren't you glad you have these tools to make compiling software so
easy?

Eric

Re: [Gimp-print-devel] building with autoconf

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

On Sun, 06 Feb 2000, sh...@al... wrote:

> > I'm probably missing something, but isn't the current
> > build mechanism to run "autoconf" and then "./configure" ?

> You need to run "aclocal" before autoconf.

Ok, works better now. Still not complete though, as ./configure
can't find Makefile.in. I might have deleted that, but it isn't
in the CVS so I guess it's not taken from there...

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

[Gimp-print-devel] Another unknown...

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

Ok, my printer simulator is coming along.  I'm going to commit some large
improvements later tonight.  It's still spitting this error, among others:

Warning: Unknown command ESC 0x8.

That's not in my docs.

Anyone?

Eric

Re: [Gimp-print-devel] building with autoconf

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

> I'm probably missing something, but isn't the current
> build mechanism to run "autoconf" and then "./configure" ?
> 
> ./configure dies straight away with
> 
> ./configure: line 524: syntax error near unexpected token `AM_INIT_AUTOMAKE(print,3.1.0)'
> ./configure: line 524: `AM_INIT_AUTOMAKE(print,3.1.0)'

You need to run "aclocal" before autoconf.

Eric

[Gimp-print-devel] building with autoconf

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

I'm probably missing something, but isn't the current
build mechanism to run "autoconf" and then "./configure" ?

./configure dies straight away with

./configure: line 524: syntax error near unexpected token `AM_INIT_AUTOMAKE(print,3.1.0)'
./configure: line 524: `AM_INIT_AUTOMAKE(print,3.1.0)'



-- 
<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] [pam.roberts@virginnet.co.uk: [linux-usb] Epson Stylus Color 760]

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

On Sun, Feb 06, 2000 at 10:24:58PM +0900, sh...@al... wr=
ote:
> > This came just in from the linux-usb mailing list. Does anybody
> > know about these initialization strings that are sent by the
> > Windows drivers? I've seen something similar with the 740 driver,
> > however the job prints even when I remove this special init string.
> > The stuation with the 760 seems to be different.
>=20
> Hmph.  Interesting.  I completely failed to get my 750 working over USB.
> I made several attempts, and then read the linux-usb mailing list archives
> and found a post from another 750 owner describing the same problems.
> I briefly joined the list, but I was overwhelmed by the traffic.
>=20
> Why doesn't Epson *document* stuff like this?  Is there some big trade
> secret hidden in this init string?

Not necessarily a trade secret. Often times companies are reluctant to give
out information to hide other things (like bad design). I don't know what
the particular reason is for Epson, but they let you get access to this=20
information after signing a NDA. One of the things you only get access to
is the ink levels in the printer. The Windows driver lets you see how=20
much ink is left in the two tanks, it also let's you clean the jets and
calibrate the print heads. All this stuff is probably hidden in some way
or another in this init string. E.g. I guess that the print head calibration
is not stored on the printer. This is probably information that the driver
sends down with every print job (or does it in software by itself).

There is a utility to do this on Linux, the author signed the NDA, and so=
=20
there is no source code, just a library that you can use in your own=20
projects: http://home.t-online.de/home/jj.sarton/startE.htm=20
There is  a link "Utilites for Epson" that downloads this tool.

Karl Heinz

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

Re: [Gimp-print-devel] [pam.roberts@virginnet.co.uk: [linux-usb] Epson Stylus Color 760]

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

   From: sh...@al...
   Date: Sun, 06 Feb 2000 22:24:58 +0900

   > This came just in from the linux-usb mailing list. Does anybody
   > know about these initialization strings that are sent by the
   > Windows drivers? I've seen something similar with the 740 driver,
   > however the job prints even when I remove this special init string.
   > The stuation with the 760 seems to be different.

   Hmph.  Interesting.  I completely failed to get my 750 working over USB.
   I made several attempts, and then read the linux-usb mailing list archives
   and found a post from another 750 owner describing the same problems.
   I briefly joined the list, but I was overwhelmed by the traffic.

   Why doesn't Epson *document* stuff like this?  Is there some big trade
   secret hidden in this init string?

Why doesn't Epson document a reasonable amount of other stuff?  Do
they really want to be the only one writing good drivers for these
printers?  I guess so...

BTW, I never got a response to my question to Epson about all this, so
I don't know what to make of 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] [pam.roberts@virginnet.co.uk: [linux-usb] Epson Stylus Color 760]

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

> This came just in from the linux-usb mailing list. Does anybody
> know about these initialization strings that are sent by the
> Windows drivers? I've seen something similar with the 740 driver,
> however the job prints even when I remove this special init string.
> The stuation with the 760 seems to be different.

Hmph.  Interesting.  I completely failed to get my 750 working over USB.
I made several attempts, and then read the linux-usb mailing list archives
and found a post from another 750 owner describing the same problems.
I briefly joined the list, but I was overwhelmed by the traffic.

Why doesn't Epson *document* stuff like this?  Is there some big trade
secret hidden in this init string?

Eric

Re: [Gimp-print-devel] One more bug in print-escp2.c

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

   From: sh...@al...
   Date: Sun, 06 Feb 2000 14:11:15 +0900

   > There are actually three commands:
   > 
   > ESC\ nl nh  is the old one
   > ESC(\ is the one used on the EX and the like (older 1440 dpi
   >       printers).  It definitely works for me.
   > ESC(/ is the newest one.

   The docs I have for the EX/700 say that the ESC(\ command is only
   valid for the EX and 700.  Can anyone verify if this command works with
   models later than these?

That particular manual covers the EX, 700, and original Photo, which
doesn't have 1440 dpi.  The manual for the older printers
(4clr_98b.pdf) indicates that it works for the 600, 800, 850, 1520,
and 3000.

-- 
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] One more bug in print-escp2.c

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

>    I just found another bug in print-escp2.c: There are two commands
>    to set the relative horizontal print position, a short one and
>    a long one:
> 
>    ESC \ nL nH
>    ESC ( / nL nH m1 m2m m3 m4
> 
>    =2E.. at least this is what my spec says. The code however implements
>    the two commands as "ESC \" (which is correct) and "ESC ( \",
>    which is wrong.

You know, I was just about to write a message pointing this out, but,
you beat me to it.  My printer simulator was written according to the
750 specs, and it barfs warning messages about unknown command ESC ( \.

> There are actually three commands:
> 
> ESC\ nl nh  is the old one
> ESC(\ is the one used on the EX and the like (older 1440 dpi
>       printers).  It definitely works for me.
> ESC(/ is the newest one.

The docs I have for the EX/700 say that the ESC(\ command is only
valid for the EX and 700.  Can anyone verify if this command works with
models later than these?

Eric

[Gimp-print-devel] More work on the dither core

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

I did a fair bit of work on the dither core tonight, as a prelude to
further decoupling the drivers from the dither stuff.  I also switched
to dynamically allocating the error buffer (this allows arbitrary page
width in addition to saving memory in most cases).  That caused a lot
of seg faults in free, which forced me to Electric Fence the whole
thing.  This called out a few other latent problems, so it's just as
well.

It's conceivable that there are still a few bad memory accesses
around, in which case you'll probably get a seg fault sooner or
later.  All we can do is squash them as they pop up.  Static error
buffers seem to not have this problem, at least on my system, but
that's not really the way we want to go...

-- 
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] [pam.roberts@virginnet.co.uk: [linux-usb] Epson Stylus Color 760]

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

This came just in from the linux-usb mailing list. Does anybody
know about these initialization strings that are sent by the
Windows drivers? I've seen something similar with the 740 driver,
however the job prints even when I remove this special init string.
The stuation with the 760 seems to be different.

Karl Heinz

----- Forwarded message from Pam R <pam...@vi...> -----

From: Pam R <pam...@vi...>
To: lin...@su...
Date: Sun, 6 Feb 2000 00:49:57 +0000
X-Mailer: KMail [version 1.0.28]
Subject: [linux-usb] Epson Stylus Color 760

FWIW I've just managed to get the EPC760 working via USB (2.2.14 kernel
with 2.3.39 backpatch) using a uniprint - stcany.upp - ghostscript
combination, by adding an extra initialisation string in stcany.upp.
The string is
   00 00 00 1b01 40 45 4a 4c 20 31 32 38 34 2e 34 0a 40 45 4a 4c 20 20
20 20 20 0a =20
Doing it this way the string is sent at the start of each print job,
but I believe that the printer really only needs it once - on the
initial connection..
Pam

---------------------------------------------------------------------
To unsubscribe, e-mail: lin...@su...
For additional commands, e-mail: lin...@su...

----- End forwarded message -----

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

Re: [Gimp-print-devel] One more bug in print-escp2.c

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

   Date: Sat, 5 Feb 2000 18:07:05 -0500
   From: Karl Heinz Kremer <kh...@kh...>


   --wac7ysb48OaltWcw
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: quoted-printable

   I just found another bug in print-escp2.c: There are two commands
   to set the relative horizontal print position, a short one and
   a long one:

   ESC \ nL nH
   ESC ( / nL nH m1 m2m m3 m4

   =2E.. at least this is what my spec says. The code however implements
   the two commands as "ESC \" (which is correct) and "ESC ( \",
   which is wrong.

   There are two places where this needs to be changed.

   It's probably faster if somebody with an already working CVS setup
   can change this. At this time I have not yet setup the user level
   access, I'm still just updating my tree with anonymous access.

Do you mean this?

      if (escp2_has_cap(model, MODEL_1440DPI_MASK, MODEL_1440DPI_YES))
	{
	  /* FIXME need a more general way of specifying column */
	  /* separation */
	  if (escp2_has_cap(model, MODEL_VARIABLE_DOT_MASK,
			    MODEL_VARIABLE_4))
	    fprintf(prn, "\033(/%c%c%c%c%c%c", 4, 0,
		    ((hoffset * 1440 / ydpi) + microoffset) & 255,
		    ((hoffset * 1440 / ydpi) + microoffset) >> 8,
		    0, 0);
	  else
	    fprintf(prn, "\033(\\%c%c%c%c%c%c", 4, 0, 160, 5,
		    ((hoffset * 1440 / ydpi) + microoffset) & 255,
		    ((hoffset * 1440 / ydpi) + microoffset) >> 8);
	}
      else
	{
	  fprintf(prn, "\033\\%c%c", hoffset & 255, hoffset >> 8);
	}

There are actually three commands:

ESC\ nl nh  is the old one
ESC(\ is the one used on the EX and the like (older 1440 dpi
      printers).  It definitely works for me.
ESC(/ is the newest one.

-- 
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] One more bug in print-escp2.c

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

I just found another bug in print-escp2.c: There are two commands
to set the relative horizontal print position, a short one and
a long one:

ESC \ nL nH
ESC ( / nL nH m1 m2m m3 m4

=2E.. at least this is what my spec says. The code however implements
the two commands as "ESC \" (which is correct) and "ESC ( \",
which is wrong.

There are two places where this needs to be changed.

It's probably faster if somebody with an already working CVS setup
can change this. At this time I have not yet setup the user level
access, I'm still just updating my tree with anonymous access.

Karl Heinz

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

Re: [Gimp-print-devel] development release?

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

   Date: Sat, 05 Feb 2000 14:40:11 -0700
   From: "S. Miller" <sm...@rn...>

   Perhaps I should have stressed more that I was only talking about the
   GUI.  To me GUIs are inherently object oriented, and it made sense to
   use C++ there.  Calling other languages from C++ is trivial, but the
   reverse is probably not the case.  What I wasn't sure of is what
   restrictions Gimp imposed.  I haven't completely figured out how
   plug-ins interface with Gimp, but since there is a main I assumed it was
   a standalone executable, and so this approach might work.  So as long as
   I can keep from bleeding into the driver code (which I guess is one of
   the main goals anyway), and keep the Makefile from breaking, I'll see
   what I can do with it.

Yup, it's a standalone executable.  The interfaces with the Gimp are
fairly straightforward-looking.

Re: [Gimp-print-devel] development release?

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

Robert L Krawitz wrote:
> 
> I have to admit that there's stuff even in the low levels that I'd
> like to use C++ for, but it's probably going to cause more problems
> than it will solve.  However, if there's one place that it really
> makes sense, it's in the GUI, which after all is not going to be
> directly portable to anything beyond the Gimp and where inheritance is
> known to be very useful.  So my take would be to lean against it, but
> if it's going to make your life radically easier and won't force the
> lower level stuff to use C++, I'd say give it a whirl.
> 
> (Besides, we might actually learn a little something about how to
> design printing interfaces in general that might just come in handy
> down the road.)
> 
Perhaps I should have stressed more that I was only talking about the
GUI.  To me GUIs are inherently object oriented, and it made sense to
use C++ there.  Calling other languages from C++ is trivial, but the
reverse is probably not the case.  What I wasn't sure of is what
restrictions Gimp imposed.  I haven't completely figured out how
plug-ins interface with Gimp, but since there is a main I assumed it was
a standalone executable, and so this approach might work.  So as long as
I can keep from bleeding into the driver code (which I guess is one of
the main goals anyway), and keep the Makefile from breaking, I'll see
what I can do with it.

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

[Gimp-print-devel] some more stupid print-util problems

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

I found a few more stupid print-util problems; any attempt to print in
multiple level mode would result in only black being printed.  That
should now be fixed.

Re: [Gimp-print-devel] development release?

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

   Date: Fri, 04 Feb 2000 19:13:04 -0700
   From: "S. Miller" <sm...@rn...>

   I would also like to toss in the notion of using C++ for some of this,
   which would facilitate custom popups by deriving them from a base
   class.  If everyone hates this, I'll keep using C, but please give it
   some thought.

My own experience (from a startup where I spent over 4 years dealing
with it) is that C++ is great for standalone stuff where everything is
written in C++, but horrible if it has to interface with anything
else.  I didn't really loathe the language -- I left that for our C++
guru, who pointed out that one really has to understand it to loathe
it in its full glory -- but it does require real expertise to use
correctly.

I have to admit that there's stuff even in the low levels that I'd
like to use C++ for, but it's probably going to cause more problems
than it will solve.  However, if there's one place that it really
makes sense, it's in the GUI, which after all is not going to be
directly portable to anything beyond the Gimp and where inheritance is
known to be very useful.  So my take would be to lean against it, but
if it's going to make your life radically easier and won't force the
lower level stuff to use C++, I'd say give it a whirl.

(Besides, we might actually learn a little something about how to
design printing interfaces in general that might just come in handy
down the road.)

-- 
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] No Success with STC 740 so far ... which printers are working?

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

   From: sh...@al...
   Date: Sat, 05 Feb 2000 23:44:08 +0900

   If you interpret this as a signed 16 bit little endian number followed by
   16 bits of trailing garbage, it makes slightly more sense, except that
   the docs specify that the printer head should never be moved in the negative
   Y direction.  Negative relative positions are only allowed for horizontal
   motion.

   Any thoughts?

It's actually very simple (to me, at any rate, and to everyone, once I
actually get around to documenting the weave code) now.

There are two concepts of where a pass starts, logical and physical.
The "logical" pass start is where the print head starts, and the
"physical" start is where the first ink is actually laid down.  This
doesn't matter except very early on, before all the jets are actually
in use.  The "physical" start can never be less than zero (the origin
for the printing), but the logical start can be.

For advancing the print head, the important thing is the delta between
the logical start of the previous pass and that of this pass (the
"logical" start is where the print head really is).  My mistake was to
simply compare it to the start of the previous pass, but when the
current pass is zero, I was comparing that number against zero (which
I initialized the "previous start" value with).

On the Photo EX, which used the two-byte version of the vertical
positioning command, it didn't cause a problem -- it was a negative
value, and was ignored (by my printer, at any rate :-) ).  On the 740,
I was feeding it two bytes of value and two bytes (the high order
bytes) of zero.  So that's a positive number, and the result was
obvious.

The fix is trivial; on pass zero don't do any vertical feed (if this
causes a problem, we'll simply give it a vertical feed of zero, but it
didn't cause me a problem) and record the logical pass start as the
previous pass start.

This (and another even more trivial problem with multi-level printing)
should be in by the time you see this.

Re: [Gimp-print-devel] No Success with STC 740 so far ... which printers are working?

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

>    My printer simulator just spits out a blank page right after the move
>    printer head down 90" command.  I still don't understand what's up with that.
> 
> Move printer head down 90"?  90 INCHES?

Yeah, inches.  I was wondering why the message I posted yesterday drew
no responses, I guess you missed the units.

In my test print from a few-days-old CVS gimp-print there's a move printer
head down 90.87 inches command:

00000055  1b  (  v 04 00 8e ff 00 00 

I'm following a strict interpretation of the docs which specifies this as
an unsigned 32 bit little endian integer number of dots, which, at 720 DPI,
translates to 90.87 inches.

If you interpret this as a signed 16 bit little endian number followed by
16 bits of trailing garbage, it makes slightly more sense, except that
the docs specify that the printer head should never be moved in the negative
Y direction.  Negative relative positions are only allowed for horizontal
motion.

Any thoughts?

Eric

Re: [Gimp-print-devel] No Success with STC 740 so far ... which printers are working?

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

   From: sh...@al...
   Date: Sat, 05 Feb 2000 23:27:53 +0900

   > My Photo EX is still working just fine.  It has to be something in the
   > new code that's going wrong...

   My printer simulator just spits out a blank page right after the move
   printer head down 90" command.  I still don't understand what's up with that.

90 inches indeed.

00000048  1b  (  v 04 00 ea ff 00 00 

That's indeed just about 90 inches.  I found another stupid
(completely unrelated) braino, so I think that I shall commit both
fixes when I've done them.

-- 
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] No Success with STC 740 so far ... which printers are working?

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

   From: sh...@al...
   Date: Sat, 05 Feb 2000 23:27:53 +0900

   > My Photo EX is still working just fine.  It has to be something in the
   > new code that's going wrong...

   My printer simulator just spits out a blank page right after the move
   printer head down 90" command.  I still don't understand what's up with that.

Move printer head down 90"?  90 INCHES?

Re: [Gimp-print-devel] No Success with STC 740 so far ... which printers are working?

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

> My Photo EX is still working just fine.  It has to be something in the
> new code that's going wrong...

My printer simulator just spits out a blank page right after the move
printer head down 90" command.  I still don't understand what's up with that.

Eric

Re: [Gimp-print-devel] No Success with STC 740 so far ... which printers are working?

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

   Date: Fri, 4 Feb 2000 20:21:09 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   Just did some quick testing with the latest CVS version and my
   stc 740. The only difference is that the pages that are produced
   are not completely blank anymore: I see thin lines every three
   or for inches when printing in 360dpi mode.=20

   Which Epson printers are working right now? I'm trying to understand
   the differences between the printers, and maybe there is something
   obvious ... So if everybody with a working Epson printer could=20
   please send me a short note with information about which modes
   are working.=20

My Photo EX is still working just fine.  It has to be something in the
new code that's going wrong...