gimp-print-devel

Re: [Gimp-print-devel] Wow!

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

   From: sh...@al...
   Date: Wed, 26 Jan 2000 00:14:49 +0900

   > 4) If you know dithering or color space theory, and you're eager to do
   >    some gnarly low level stuff, that's also useful.

   I do gnarly low level stuff best.  I'll look into it, but I have to be up
   early tomorrow, so, not tonight.

OK.

   I don't have a lot of experience here, but I've read up on the
   publicly available documentation on the web and I have the CIElab
   coordinate measurements of the inks used in the ESP750.  I don't
   know if these are used in the current print plugin or not.

They're not, but that would be useful information.  Currently there's
some weird ratio stuff going on.  That would best be replaced by
actual data.

The other thing that's wrong is that those ratios are hardcoded, so
printers with different inks won't do the right thing.  The right
thing is for there to be an initialization/free routine for each
dithering routine that is called by the printer driver.  That would go
a long way to fixing the static variable problem.  The init routine
should return an opaque handle (i. e. pointer) to an object specific
to each class of dither routine that contains all the information
required by that routine (including the error rows and all that).

Another change I would like to see done is in the dataflow between the
driver and the dither routine.  Currently the driver presents the
dither routine a line of input and an output line that must be filled
in.  I would prefer that the dither routine initialization routine
take a callback from the driver, so that the dither routine can
process as many lines as it likes before actually outputting
anything.  This would allow us to use more sophisticated dithering
routines.

Interested in 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...

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

Re: [Gimp-print-devel] Wow!

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

> 4) If you know dithering or color space theory, and you're eager to do
>    some gnarly low level stuff, that's also useful.

I do gnarly low level stuff best.  I'll look into it, but I have to be up
early tomorrow, so, not tonight.

I don't have a lot of experience here, but I've read up on the publicly
available documentation on the web and I have the CIElab coordinate
measurements of the inks used in the ESP750.  I don't know if these are used
in the current print plugin or not.

Eric

Re: [Gimp-print-devel] Wow!

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

> That's no problem, just get yourself an Epson scanner and hook it
> up to the printer so that you can view every page the printer
> produces. Did I mention that I maintain the Sane Epson backend :-)

Unfortunately our current scanner is unsupported as well. :(  I guess
I'll have to have her put the digital camera in front of the printer and
run the serial line from the camera to the server.  I can snap photos
remotely using gphoto.  :)

Eric

Re: [Gimp-print-devel] Wow!

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

   From: sh...@al...
   Date: Tue, 25 Jan 2000 22:58:50 +0900

   I was figuring that it would take me some time to get a lot of the details
   of color space conversions correct, so I was starting now in the hopes of
   having a working but untuned version by the time I got home.

Tuning the color and dithering stuff in general is a real pain in the
patooie.  Anyone else who wants to have a crack at it is welcome :-)

   > Henryk Richter (whom I hope subscribes to the list shortly) ported the
   > 3.0.5 version of the plugin (or at least the Epson piece) to
   > Ghostscript.

   Gee you guys work fast.  According to your home page that hasn't been done
   yet!

Well, partly I don't update my home page very often, and partly it
isn't complete yet...

   > It doesn't entirely work yet; there are some problems
   > with static variables (mine, not his) with more than one output page,
   > but we should be able to fix that fairly quickly.  When that's fixed
   > up Henryk or I will post it to the project.

   Ok, so, what's left to do?  Since you guys obviously have a huge
   lead on me, at this point I think I should drop back and put what
   resources I have under your disposal.  I'm primarily a coder
   (sorry, I'm not really interested in improving the web page) so if
   there's anything that you want coded or debugged please let me
   know.

Check out the development roadmap on the project page (it's in the
News section in the bottom right).  There are a number of things that
I think would be useful:

1) Do a proper Configure script, so that it can be built standalone.

2) The UI and gimp interface (print.c) is a real mess, and desperately
   needs a cleanup.

3) It sounds like you're an Epson type, so I won't mention support for
   other vendors' printers, but that's always useful.

4) If you know dithering or color space theory, and you're eager to do
   some gnarly low level stuff, that's also useful.

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

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

Re: [Gimp-print-devel] Wow!

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

sh...@al... said: 
[ ... ]
> my past message.  The printer is at home and I'm currently at work. 
(That
> may sound like a strange thing to call a hitch, but, in high energy
physics
> these two are often quite distant.  About 7000 miles in my case.) 
There's
> a lot I can do remotely, but, it has some limitations.  My wife is 

That's no problem, just get yourself an Epson scanner and hook it
up to the printer so that you can view every page the printer
produces. Did I mention that I maintain the Sane Epson backend :-)

Karl Heinz

[Gimp-print-devel] Please register as a developer!

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

Actually, just a quick update -- I think you need to visit the
Developer Info page on sourceforge and send me a message that way; I
suspect that that message will give me the method to accept you.  So
everyone should have a SourceForge account to do this.  Sorry for the
confusion...

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

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

Re: [Gimp-print-devel] Wow!

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

> The good news is that I just checked in preliminary support for the
> 750 last night.  It probably won't actually work, but it's not
> impossible that it will "just work" out of the can.  It generates
> lexically correct commands, but it's possible that the arguments
> aren't entirely correct or that the mixture of old (700/EX vintage)
> and new commands will not work either.  But give it a try.

I'll see what I can do.  There's one small hitch that I didn't mention in
my past message.  The printer is at home and I'm currently at work.  (That
may sound like a strange thing to call a hitch, but, in high energy physics
these two are often quite distant.  About 7000 miles in my case.)  There's
a lot I can do remotely, but, it has some limitations.  My wife is home
and she uses the printer (actually, I bought the printer for her, I'm just
trying to get her to use Linux more) so I'll be doing most of my testing
through her.

I was figuring that it would take me some time to get a lot of the details
of color space conversions correct, so I was starting now in the hopes of
having a working but untuned version by the time I got home.

> Henryk Richter (whom I hope subscribes to the list shortly) ported the
> 3.0.5 version of the plugin (or at least the Epson piece) to
> Ghostscript.

Gee you guys work fast.  According to your home page that hasn't been done
yet!

> It doesn't entirely work yet; there are some problems
> with static variables (mine, not his) with more than one output page,
> but we should be able to fix that fairly quickly.  When that's fixed
> up Henryk or I will post it to the project.

Ok, so, what's left to do?  Since you guys obviously have a huge lead on
me, at this point I think I should drop back and put what resources I have
under your disposal.  I'm primarily a coder (sorry, I'm not really interested
in improving the web page) so if there's anything that you want coded or
debugged please let me know.

Eric

[Gimp-print-devel] Please register as a developer!

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

I think that I need to approve each person who wants to be added as a
developer (which gives you write access to the repository, and other
goodies), so if you'd like to be added, please drop me a line and I'll
try to work my way through the maze of menus to add you.

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

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

Re: [Gimp-print-devel] Wow!

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

   From: sh...@al...
   Date: Tue, 25 Jan 2000 22:26:25 +0900

   For the past week or so I've been trying to figure out how to
   improve support for my ESP 750 under Linux.

The good news is that I just checked in preliminary support for the
750 last night.  It probably won't actually work, but it's not
impossible that it will "just work" out of the can.  It generates
lexically correct commands, but it's possible that the arguments
aren't entirely correct or that the mixture of old (700/EX vintage)
and new commands will not work either.  But give it a try.

   My primary interest is not particularly related to the Gimp.  I
   originally wanted to get 6-color printing support in Ghostscript.
   I've done some reviews of the code and it seems that this will
   require a bit of work, but isn't impossible.  However I've really
   just begun and I haven't produced any code yet.  I'm very
   interested to see what work I can do to integrate what you have
   done into ghostscript.  I want to work with Gunther Hess' Uniprint
   driver, which is quite flexible by design and already interacts
   well with the ESC740.

Henryk Richter (whom I hope subscribes to the list shortly) ported the
3.0.5 version of the plugin (or at least the Epson piece) to
Ghostscript.  It doesn't entirely work yet; there are some problems
with static variables (mine, not his) with more than one output page,
but we should be able to fix that fairly quickly.  When that's fixed
up Henryk or I will post it to the project.

BTW, does anyone feel like developing a better web site for the
project than my home page?  I'm not likely to have much time to.

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

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

Re: [Gimp-print-devel] Some commits

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

   Date: Tue, 25 Jan 2000 07:50:04 -0500
   From: Karl Heinz Kremer <kh...@kh...>

    case 720 :
      if (escp2_has_cap(model, MODEL_VARIABLE_DOT_MASK, MODEL_VARIABLE_4))
	fwrite("\033(U\005\000\002\002\001\240\005", 10, 1, prn);
      else
	fwrite("\033(U\001\000\005", 6, 1, prn);
      break;

BTW, I missed your earlier message about the extended set unit
command.  There was in fact a bug where it wasn't passing the last two
bytes; I fixed that in my commits last night.

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

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

[Gimp-print-devel] 3.0.5 requirements

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

3.0.5 will build on 1.0.4; you need to put -DGIMP_1_0 on the
compilation command line.

As for the issue of printing on a Stylus 400, I'm pretty certain that
this plugin supports it.  Henryk Richter actually ported it to
Ghostscript, but there are a few problems left with static variables
that we need to clean up.  He reports that print quality when used as
a Ghostscript driver is just as good as the print quality from the
Gimp, so when that's releasable it will provide another option for
printing out 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...

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

[Gimp-print-devel] Wow!

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

Wow!

For the past week or so I've been trying to figure out how to improve support
for my ESP 750 under Linux.  I've been exchanging mail on this topic with
Dale Pontius (Author of Stylus Color 740 uniprint drivers), who referred
me to Michael Sweet (who you know, and who gave me some helpful info), and
I've also independently contacted L. Peter Deutsch (gh...@al..., in
charge of ghostscript) who referred me to Uli Wortmann, Gunther Hess, and
Martin Lottermoser (all three of whom I have exchanged mail with) as active
inkjet printer driver developers.  And through all of that exchange, I
hadn't heard a word about your work.

However, not 10 minutes ago, I was chatting with a colleague I work with
about this and out of the blue he mentions this project.  All I can say is,
wow!

Anyway, I am *very* interested in what you're doing right now.  I haven't
yet had time to review the details of what you have accomplished.  I just
wanted to get this message off immediately before reading the code.

Let's see, I'm supposed to "send a short message to the list introducing
yourself and your interest in improving the Gimp's printing capabilities".

Name:  Eric Sharkey
Oxygen Consumption Experience : 26 years
Computer Programming Experience: 18 years
C Programming Experience: 6 years
Linux Experience: 4.5 years
ESP 750 Experience: 4 months
Current Occupation: High Energy Physics PhD Student (5th year)

My primary interest is not particularly related to the Gimp.  I originally
wanted to get 6-color printing support in Ghostscript.  I've done some reviews
of the code and it seems that this will require a bit of work, but isn't
impossible.  However I've really just begun and I haven't produced any
code yet.  I'm very interested to see what work I can do to integrate what
you have done into ghostscript.  I want to work with Gunther Hess' Uniprint
driver, which is quite flexible by design and already interacts well with
the ESC740.

I guess that's all I have to say for the moment.  I look forward to reading
your code.

Eric

Re: [Gimp-print-devel] Some commits

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

   Date: Tue, 25 Jan 2000 07:50:04 -0500
   From: Karl Heinz Kremer <kh...@kh...>
   Cc: gim...@so...

   Robert L Krawitz <rl...@al...> said: 
   [ ... ]
   > 
   > I believe it.  The way the ESC( commands work, the first byte after
   > ESC(<char> is a byte count for the rest of the command.

   Correct me if I'm wrong, but I think the first two bytes are the
   byte count (low byte and hight byte). So the short version has "1 0"
   and the new 740 version "5 0", which makes it seven parameters 
   total. 

You're correct.

   >    What was your source of information for the five parameter
   version?=20

   The document 4clr_99a.pdf on the ercipd site, page 29.
   > 
   > http://www.ercipd.com/isv/edr_docs.htm

   In escp2_init_printer your ESC(U command takes only five
   arguments including the byte count, so I guess what you 
   are saying is that there are only two versions of this
   command, and the new version should have to more parameters?

Right, there are two versions -- the regular and the "extended"
version.  The new code has both, depending upon the kind of printer:

    case 720 :
      if (escp2_has_cap(model, MODEL_VARIABLE_DOT_MASK, MODEL_VARIABLE_4))
	fwrite("\033(U\005\000\002\002\001\240\005", 10, 1, prn);
      else
	fwrite("\033(U\001\000\005", 6, 1, prn);
      break;

The new command sequence is a lot more logical than the old; I just
have to finish the conversion.  It wouldn't entirely surprise me if
they don't mix very well.

   PS: Is it necessary that I reply to your mail address and
   CC the list, or can I just reply to the list?

Just me is OK.

BTW, here's a perl script that I use to lex Epson print files that I
wrote a while back to help me.  I'm going to put it in the
repository.  It doesn't actually translate anything, just analyzes the
lexical tokens.


#!/usr/bin/perl

while (<>) {
    $stuff .= $_;
}

%seqtable = ( "@", 0,
	      "(G", "VARIABLE",
	      "(U", "VARIABLE",
	      "U", 1,
	      "(K", 4,
	      "(i", "VARIABLE",
	      "(e", "VARIABLE",
	      "(c", "VARIABLE",
	      "(V", "VARIABLE",
	      "(v", "VARIABLE",
	      "(S", "VARIABLE",
	      "(r", "VARIABLE",
	      "(/", "VARIABLE",
	      "(\$", "VARIABLE",
	      "(D", "VARIABLE",
	      "(R", "VARIABLE",
	      "\\", 2,
	      "\$", 2,
	      "(\\", "VARIABLE",
	      "(C", "VARIABLE",
	      "r", 1,
	      ".", "SPECIAL",
	      "i", "SPECIAL1"
	  );

$esc = "\033";

$skipcount = 0;
$curpos = 0;
$verbose = 0;

sub do_special_command {
    print "\n";
    printf "%08x  ", $curpos;
    print "1b ";
    for ($i = 1; $i < 8; $i++) {
	$char = substr($stuff, $i, 1);
	$nchar = unpack("C", $char);
	if ($i < 2 && $nchar >= 32 && $nchar < 127) {
	    print " $char ";
	} else {
	    printf "%02x ", unpack("C", $char);
	}
    }
    $comptype = unpack("C", substr($stuff, 2, 1));
    $dots = unpack("v", substr($stuff, 6, 2));
    $something = unpack("C", substr($stuff, 5, 1));
    print " ($dots, $something) ";
    $savedots = $dots;
    $dots *= $something;
    $curpos += 8;
    substr($stuff, 0, 8) = "";
    if ($comptype == 0) {
	$bytes = ($dots + 7) / 8;
	if ($verbose) {
	    for ($k = 0; $k < $bytes; $k++) {
		$char = substr($stuff, $i, 1);
		printf "%02x", unpack("C", $char);
	    }
	}
	$curpos += $bytes;
	substr($stuff, 0, $bytes) = "";
    } elsif ($comptype == 1) {
	while ($something > 0) {
	    $dots = $savedots;
	    while ($dots > 0) {
		$counter = unpack("C", substr($stuff, 0, 1));
		$curpos++;
		substr($stuff, 0, 1) = "";
		if ($counter <= 127) {
		    $counter++;
		    if ($verbose) {
			for ($k = 0; $k < $counter; $k++) {
			    $char = substr($stuff, $i, 1);
			    printf "%02x ", unpack("C", $char);
			}
		    }
		    $curpos += $counter;
		    substr($stuff, 0, $counter) = "";
		    $dots -= 8 * $counter;
		} else {
		    $counter = 257 - $counter;
		    if ($verbose) {
			for ($k = 0; $k < $counter; $k++) {
			    $char = substr($stuff, 0, 1);
			    printf "%02x ", unpack("C", $char);
			}
		    }
		    $curpos++;
		    substr($stuff, 0, 1) = "";
		    $dots -= 8 * $counter;
		}
	    }
	    $something--;
	}
    } else {
	print "\nUnknown compression type $comptype!\n";
    }
}

sub do_special1_command {
    print "\n";
    printf "%08x  ", $curpos;
    print "1b ";
    for ($i = 1; $i < 9; $i++) {
	$char = substr($stuff, $i, 1);
	$nchar = unpack("C", $char);
	if ($i < 2 && $nchar >= 32 && $nchar < 127) {
	    print " $char ";
	} else {
	    printf "%02x ", unpack("C", $char);
	}
    }
    $comptype = unpack("C", substr($stuff, 3, 1));
    $bitsperpixel = unpack("C", substr($stuff, 4, 1));
    $dots = unpack("v", substr($stuff, 5, 2));
    $something = unpack("v", substr($stuff, 7, 2));
    print " ($dots, $something, $bitsperpixel) ";
    $dots *= 8;
    $savedots = $dots;
    $dots *= $something;
    $curpos += 9;
    substr($stuff, 0, 9) = "";
    if ($comptype == 0) {
	$bytes = ($dots + 7) / 8;
	if ($verbose) {
	    for ($k = 0; $k < $bytes; $k++) {
		$char = substr($stuff, $i, 1);
		printf "%02x", unpack("C", $char);
	    }
	}
	$curpos += $bytes;
	substr($stuff, 0, $bytes) = "";
    } elsif ($comptype == 1) {
	while ($something > 0) {
	    $dots = $savedots;
	    while ($dots > 0) {
		$counter = unpack("C", substr($stuff, 0, 1));
		$curpos++;
		substr($stuff, 0, 1) = "";
		if ($counter <= 127) {
		    $counter++;
#		    printf(" (%d) ", $counter);
		    if ($verbose) {
			for ($k = 0; $k < $counter; $k++) {
			    $char = substr($stuff, $i, 1);
			    printf "%02x ", unpack("C", $char);
			}
		    }
		    $curpos += $counter;
		    substr($stuff, 0, $counter) = "";
		    $dots -= 8 * $counter;
		} else {
		    $counter = 257 - $counter;
#		    printf(" (%d %d) ", $counter, unpack("C", substr($stuff, 0, 1)));
		    if ($verbose) {
			$char = substr($stuff, 0, 1);
			for ($k = 0; $k < $counter; $k++) {
			    printf "%02x ", unpack("C", $char);
			}
		    }
		    $curpos++;
		    substr($stuff, 0, 1) = "";
		    $dots -= 8 * $counter;
		}
	    }
	    $something--;
	}
    } else {
	print "\nUnknown compression type $comptype!\n";
    }
}

while ($stuff ne "") {
    if (substr($stuff, 0, 1) eq "$esc") {
	$found = 0;
	foreach $key (keys %seqtable) {
	    if (substr($stuff, 1, length $key) eq $key) {
		$skipchars = $seqtable{$key};
		if ($skipchars eq "SPECIAL") {
		    do_special_command;
		    $found = 2;
		} elsif ($skipchars eq "SPECIAL1") {
		    do_special1_command;
		    $found = 2;
		} else {
		    print "\n";
		    printf "%08x  ", $curpos;
		    print "1b ";
		    $startoff = 0;
		    if ($skipchars eq "VARIABLE") {
			$lchar = substr($stuff, (length $key) + 1, 1);
			$nlchar = unpack("C", $lchar);
			$hchar = substr($stuff, (length $key) + 2, 1);
			$nhchar = unpack("C", $hchar);
			$skipchars = ($nhchar * 256) + $nlchar;
			$startoff = 2;
		    }
		    for ($i = 0;
			 $i < $skipchars + (length $key) + $startoff;
			 $i++) {
			$char = substr($stuff, $i + 1, 1);
			$nchar = unpack("C", $char);
			if ($i < 2 && $nchar >= 32 && $nchar < 127) {
			    print " $char ";
			} else {
			    printf "%02x ", unpack("C", $char);
			}
		    }
		    $found = 1;
		}
		$bytes = length($key) + 1 + $skipchars + $startoff;
		last;
	    }
	}
	if (! $found) {
	    print "\n";
	    printf "%08x  ", $curpos;
	    print "1b ";
	    substr($stuff, 0, 1) = "";
	    $curpos += 1;
	} elsif ($found == 1) {
	    substr($stuff, 0, $bytes) = "";
	    $curpos += $bytes;
	} else {
	}
    } else {
	$char = substr($stuff, 0, 1);
	$nchar = unpack("C", $char);
	if ($nchar >= 32 && $nchar < 127) {
	    print " *$char ";
	} else {
	    printf "*%02x ", unpack("C", $char);
	}
	$curpos++;
	substr($stuff, 0, 1) = "";
    }
}

Re: [Gimp-print-devel] Some commits

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

Robert L Krawitz <rl...@al...> said: 
[ ... ]
> 
> I believe it.  The way the ESC( commands work, the first byte after
> ESC(<char> is a byte count for the rest of the command.

Correct me if I'm wrong, but I think the first two bytes are the
byte count (low byte and hight byte). So the short version has "1 0"
and the new 740 version "5 0", which makes it seven parameters 
total. 

> 
>    What was your source of information for the five parameter
version?=20

The document 4clr_99a.pdf on the ercipd site, page 29.
> 
> http://www.ercipd.com/isv/edr_docs.htm
> 

In escp2_init_printer your ESC(U command takes only five
arguments including the byte count, so I guess what you 
are saying is that there are only two versions of this
command, and the new version should have to more parameters?

Karl Heinz

PS: Is it necessary that I reply to your mail address and
CC the list, or can I just reply to the list?

Re: [Gimp-print-devel] Some commits

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

   Date: Mon, 24 Jan 2000 22:41:26 -0500
   From: Karl Heinz Kremer <kh...@kh...>
   Cc: gim...@so...

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

   On Mon, Jan 24, 2000 at 10:36:41PM -0500, Robert L Krawitz wrote:
   > I've committed a number of things to the repository:
   >=20
   > 1) Preliminary code for the Epson Stylus Color 440/640/740/900, Epson
   >    Stylus Photo 750/1200.  I don't expect it to work, because I'm
   >    using a mix of old-style and new-style commands, although it's not
   >    entirely beyond the realm of possibility that it will.  For now,
   >    though, it generates basically the right bits.

   Aha, so I was probably to quick to test and complain :-)

   The "new-style" commands are not working with the 740. As I already=20
   mentioned, the ESC(U has to wrong number of arguments. I'm not too
   familiar with ESC/P, so I just assumed that there is a form with
   three, five and seven arguments. The longer I think about it the
   less likely I think this is, esp. because both the five and seven
   argument version would not be using the same code (05) after the=20
   command.=20

Hmm.  According to my manual, the new-style ESC(U command works with
the 740, and the arguments I gave it appear to be exactly the same as
the arguments that I have from a printout on a 750 that someone gave
me.  I think the real problem is that right now I'm being
inconsistent, using a mix of old and new style commands.  I expected
that that wouldn't work.

   What was your source of information for the five parameter version?=20

http://www.ercipd.com/isv/edr_docs.htm

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

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

Re: [Gimp-print-devel] Some commits

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

   Date: Mon, 24 Jan 2000 22:41:26 -0500
   From: Karl Heinz Kremer <kh...@kh...>
   Cc: gim...@so...


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

   On Mon, Jan 24, 2000 at 10:36:41PM -0500, Robert L Krawitz wrote:
   > I've committed a number of things to the repository:
   >=20
   > 1) Preliminary code for the Epson Stylus Color 440/640/740/900, Epson
   >    Stylus Photo 750/1200.  I don't expect it to work, because I'm
   >    using a mix of old-style and new-style commands, although it's not
   >    entirely beyond the realm of possibility that it will.  For now,
   >    though, it generates basically the right bits.

   Aha, so I was probably to quick to test and complain :-)

   The "new-style" commands are not working with the 740. As I already=20
   mentioned, the ESC(U has to wrong number of arguments. I'm not too
   familiar with ESC/P, so I just assumed that there is a form with
   three, five and seven arguments. The longer I think about it the
   less likely I think this is, esp. because both the five and seven
   argument version would not be using the same code (05) after the=20
   command.=20

I believe it.  The way the ESC( commands work, the first byte after
ESC(<char> is a byte count for the rest of the command.

   What was your source of information for the five parameter version?=20

http://www.ercipd.com/isv/edr_docs.htm

Re: [Gimp-print-devel] Some commits

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

On Mon, Jan 24, 2000 at 10:36:41PM -0500, Robert L Krawitz wrote:
> I've committed a number of things to the repository:
>=20
> 1) Preliminary code for the Epson Stylus Color 440/640/740/900, Epson
>    Stylus Photo 750/1200.  I don't expect it to work, because I'm
>    using a mix of old-style and new-style commands, although it's not
>    entirely beyond the realm of possibility that it will.  For now,
>    though, it generates basically the right bits.

Aha, so I was probably to quick to test and complain :-)

The "new-style" commands are not working with the 740. As I already=20
mentioned, the ESC(U has to wrong number of arguments. I'm not too
familiar with ESC/P, so I just assumed that there is a form with
three, five and seven arguments. The longer I think about it the
less likely I think this is, esp. because both the five and seven
argument version would not be using the same code (05) after the=20
command.=20

What was your source of information for the five parameter version?=20

Karl Heinz


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

[Gimp-print-devel] Some commits

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

I've committed a number of things to the repository:

1) Preliminary code for the Epson Stylus Color 440/640/740/900, Epson
   Stylus Photo 750/1200.  I don't expect it to work, because I'm
   using a mix of old-style and new-style commands, although it's not
   entirely beyond the realm of possibility that it will.  For now,
   though, it generates basically the right bits.

2) The save/load printrc code is now a bit more deterministic (you're
   a bit more likely to get restored settings the same as the settings
   you saved).

3) A handful of bug fixes.

I've received code from Henryk Richter to convert the Epson Stylus
driver into a Ghostscript driver.  It has problems (mine, in the form
of static variables in the driver stuff; he did his side correctly :-)
), so we're not releasing it quite yet.  Hopefully within the next
couple of days.  This will be based on 3.0.5 rather than 3.1.  Henryk
says that it produces very nice output from Ghostscript.  This, of
course, is one of the major development goals for 3.2, and I'm really
thrilled to see this happen.

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

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

[Gimp-print-devel] Re: epson printers

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

   Date: Mon, 24 Jan 2000 14:37:52 +0100
   From: Hrafnkell Eiriksson <he...@kv...>

   I saw on slashdot (discussion about the CUPS printing system) that
   you have done some work on programming the Epson Photo printers.
   I'm interested in getting an Epson printer, possibly an Epson Photo 750.
   Is the documentation for the Epson printers publicly available?
   If so, where? I'd like if I could help myself if I was not happy with
   the printing results :)

I'm working on support for it right now, but I don't have one to test
it on.  There is documentation available at
http://www.ercipd.com/isv/edr_docs.htm.

You might want to register on sourceforge.net (the gimp-print project
is https://sourceforge.net/project/?group_id=1537), and check out the
sources from CVS.

   On your webpage I see that you code has not yet been ported to the
   Epson Photo 750. Do you know what is needed? Would you maybe reccomend
   any other printer to use with Linux. I need to print reports written
   in LaTeX that sometimes include photographic pictures (I'm studying
   image processing).

Well, the Stylus Photo 700/EX (the older series photo printers) are
very well supported (that's the one that I have :-) ).  Henryk Richter
ported one of the intermediate versions of the driver to Ghostscript,
so it could be used as a general printing solution.  However, there
are still some bugs in it that I hope to eliminate shortly.

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

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

[Gimp-print-devel] Extended Set Unit fails for stc740 (and stc900 ?)

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

I think I found the reason why my stc740 is not printing:

The "Set Unit (extended)" command ("ESC(U") for the 740 and the 900
takes seven arguments. The software however passes only five
parameters (or three for the older printers). I guess we need another
model variant for these two printers.

Karl Heinz

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

[Gimp-print-devel] Re: gimp-print3.x escp2 bugs and Stylus Photo ghostscript driver

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

BTW, how does the print quality of your ghostscript driver compare to
the one that's already in there?  How does it compare to the Gimp
plugin?

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

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

[Gimp-print-devel] Re: gimp-print3.x escp2 bugs and Stylus Photo ghostscript driver

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

   Date: Sun, 23 Jan 2000 20:19:23 +0200
   From: Henryk Buggs Richter <tf...@ck...>

   Warning: This is a message in MIME format. Your mail reader does not
   support MIME. Some parts of this message will be readable as plain text.
   To see the rest, you will need to upgrade your mail reader.

   --Boundary_(ID_aZWnBBH/dy9w5r/HBAI2Lw)
   Content-type: text/plain; CHARSET=US-ASCII

   Hello Robert,

   I`ve enjoyed using your gimp print plugin in conjunction with
   my Epson Photo 700 for a while.

   Unfortunately most programs only produce PS output and 
   ghostscript`s support for 6 color Epson Injets was weak.

   So I grabbed your escp2 driver and wrote a ghostscript
   wrapper for it. I hope it`s useful for you too and I`d be
   glad if you add it to your web page. I tested it only on
   my Photo 700 with A4 paper by now. The only changes to
   your driver were a different name of the include file
   and bottom=50 for MODEL_IMAGEABLE_PHOTO. I used
   ghostscript V5.99beta as starting point for my work.

WONDERFUL!!!!!!!!!!

This is one of the primary gimp-print 3.2 development goals.  And now
I find somebody's just done did it.  Actually, the print-pcl driver
should receive the same kind of treatment (I'm guessing that it won't
be very hard at all).  I actually want all the smarts in gimp-print to
eventually go away, to be replaced by a thin glue layer between the
Gimp and "the Linux printing system".

Henryk, could you please surf over to
https://sourceforge.net/project/?group_id=1537, join SourceForge and
the gimp-print project, and put this stuff in the CVS repository
there?  I'm obviously not going to refuse this kind of thing in any
form, but it will probably go in most smoothly if you do it yourself.

   While testing I noticed some bugs in your code. 

   Mode 9 (1440 x 720 DPI Two-pass Microweave) uses
   wrong scaling in the x direction resulting in pictures
   4 times as wide as supposed to be.

Thanks.  I'll take a look at it.  I've been looking at the weaving
code today, and just seeing how broken it is.

   All softweave modes don`t produce printer linefeeds 
   with OUTPUT_GRAY.

Thanks.

   Hoping not annoying you with this 
   large unwanted mail,

Absolutely not.  This is a really big piece of progress.

[Gimp-print-devel] Does not work with stc740

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

The current CVS version (23-Jan-2000 about 11:00 EST) does not work
with my Epson stc740: When I try to print something from within Gimp
I only get formfeeds on my printer. Does anybody know about a ESC/P
disassembler, that I could use to see what's in the output stream?

BTW: When I say I am only getting formfeeds, I mean lots of them.
I killed the job after about 10 blank pages.

Karl Heinz

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

[Gimp-print-devel] 3.0.5: requirements?

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

Dear Team,

I have downloaded gimp print 3.0.5, and tried to compile it on my RH 6.1
system (with kernel 2.2.14).  I was unsuccessful.  Before I spend much
more of my precious time,

  1. Will this work with gimp 1.04?
  2. are there any other special requirements?
  3. do you have any suggestion of the simplest way to get it working
     with 1.0.4?
  4. I modified the Makefile.standalone with the following patch, but
     the file print.c was trying to include a file libgimp/gimpintl.h
     that does not exist on my system.  (where can I get it?  Is it
     necessary to massively upgrade my system?).  If I comment the
     #include line out, the macro N_() becomes undefined.
  5. I would be grateful for any suggestions.
  6. I want to print out photos on our Epson Stylus 400.  Any
     alternative suggestions greatly appreciated.  I have found the best
     results so far using the Red Hat print filters and lpr (and
     ghostscript).  But I believe that better results are possible.

1021 # diff -u Makefile.standalone Makefile.standalone-n2
--- Makefile.standalone Thu Jan 13 11:29:16 2000
+++ Makefile.standalone-n2      Sun Jan 23 17:06:58 2000
@@ -16,14 +16,14 @@

 # Locations of various and sundry items.  Edit to taste.

-PREFIX = /usr/local
+PREFIX = /usr
 LIBRARIES = /lib
 HEADERS = /include
-GIMPVERSION = 1.1
+GIMPVERSION = 1.0
 BINDIR = $(PREFIX)/$(LIBRARIES)/gimp/$(GIMPVERSION)/plug-ins
 GIMPINCLUDE = -I$(PREFIX)$(HEADERS)/libgimp
-GLIBINCLUDE = -I/usr/local/glib/include -I/usr/lib/glib/include
-LOCALEDIR=/usr/local/share/locale
+GLIBINCLUDE = -I/usr/glib/include -I/usr/lib/glib/include
+LOCALEDIR=/usr/share/locale
 X11DIR = /usr/X11R6

 OPTLEVEL = -O6 -funroll-all-loops -Wall
@@ -39,7 +39,8 @@

 LPSTATCOMMAND =        -DLPSTAT_COMMAND=\"/usr/bin/lpstat\"
 LPCCOMMAND =   -DLPC_COMMAND=\"/usr/sbin/lpc\"
-LPCOMMAND =    -DLP_COMMAND=\"/usr/bin/lp\"
+# LPCOMMAND =  -DLP_COMMAND=\"/usr/bin/lp\"
+LPCOMMAND =    -DLP_COMMAND=
 LPRCOMMAND =   -DLPR_COMMAND=\"/usr/bin/lpr\"
 CFLAGS = $(OPTLEVEL) $(INCLUDES) $(LPSTATCOMMAND) $(LPCCOMMAND) $(LPCOMMAND) $(LPRCOMMAND) -DLOCALEDIR=\"$(LOCALEDIR)\"

--
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 8674   Fax: (852) 2436 8643
pgp ID: 7529555D fingerprint: 53 B6 6D 73 52 EE 1F EE EC F8 21 98 45 1C 23 7B

[Gimp-print-devel] Re: Print stuff

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

   Date: Fri, 21 Jan 2000 08:40:02 +0100
   From: Andy Thaller <th...@ph...>

   Robert L Krawitz wrote:

   > It's really the constants that will probably be wrong for you.  The
   > dithering routines themselves will probably work, unless Canon
   > supports some ridiculous number of levels (dot sizes) of each color.

   Not that I'd know.

You might need to hunt around for documentation.  Canon's making
claims that they have 33 some odd gradations of color, which might
mean 33 different dot sizes, or it might not.

   > The MODEL_6COLOR actually refers to CcMmYK (light cyan and magenta).
   > The routine, however, should work for CcMmYy or CcMmYyK just fine.

   Ah yes, silly me - don't know where I've got that CcMmYy
   from. Meanwhile I've had another look at the documentation and it
   says it's really CcMmYK.

CcMmYy isn't necessarily a silly way to do things...

   Yesterday night I've got my first test-print @ 360x360 dpi and it
   looked quite ok - I'll have to play with the gamma and
   horizontal/vertical offsets but the basics work. I'll let you know
   when there's more.

Great!

   Regarding the 6-color mode: since there are 3 possible modes to
   print in (B&W / CMYK / CcMmYK) it would be good to have a way to
   choose between them.  The canon driver for windows has a pull down
   list for this purpose, but radiobuttons as in the print-plugin seem
   ok to me - there'd just have to be a way to check which mode a
   printer supports. What do you think?

There's already a choice between BW and color.  For now, until we redo
the whole dialog thing, what I'd suggest is having two different
printers, Canon Foobar 3000 (4-color) and Canon Foobar 3000 (Photo) or
some such.

This is obviously not the way we want to go, but it's a way to get
things working quickly.

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

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