gimp-print-devel

Re: [Gimp-print-devel] Ghostscript

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

   Date: Fri, 28 Jan 2000 19:21:04 -0500
   From: Robert L Krawitz <rl...@al...>
   CC: gim...@so...

      From: sh...@al...
      Date: Fri, 28 Jan 2000 23:30:24 +0900

      > Henryk's having some problems with
      > his Sourceforge account, so he asked me to do this for him.

      Ah, so it's not just me?

      I've filed bug 101232 on SourceForge describing my problems
      connecting to the CVS repository as user sharkey.  It's been
      assigned to someone, but no response yet.

   Is it just problems connecting to the CVS repository -- can you do
   other stuff just fine?  I wonder if it's a permission problem of some
   kind in the repository tarball I gave them to start things off.

I pulled down a CVS tarball, and the permissions on the files look
right to me.

Re: [Gimp-print-devel] Ghostscript

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

   From: sh...@al...
   Date: Fri, 28 Jan 2000 23:30:24 +0900

   > Henryk's having some problems with
   > his Sourceforge account, so he asked me to do this for him.

   Ah, so it's not just me?

   I've filed bug 101232 on SourceForge describing my problems
   connecting to the CVS repository as user sharkey.  It's been
   assigned to someone, but no response yet.
   
Is it just problems connecting to the CVS repository -- can you do
other stuff just fine?  I wonder if it's a permission problem of some
kind in the repository tarball I gave them to start things off.

   I want to commit the prototype for the escp2 to ppm converter soon.
   It's not done yet, but, I've been using CVS for all my work for the
   past three years, and now I get itchy when I'm working on something
   outside of CVS control.  I prefer the commit early, commit often
   method.

Early on when I started working on this I had problems before I
started checking stuff into (my local) repository.  I definitely agree
with you.

Re: [Gimp-print-devel] Ghostscript

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

> Henryk's having some problems with
> his Sourceforge account, so he asked me to do this for him.

Ah, so it's not just me?

I've filed bug 101232 on SourceForge describing my problems connecting
to the CVS repository as user sharkey.  It's been assigned to someone,
but no response yet.

I've tried this from three different systems now.  Originally I tried it
from my laptop, which was running OpenSSH and behind a firewall.  I found
a system which was running the non-free ssh and one that was not behind a
firewall, but, in both cases the results were the same.  It's strange.

I want to commit the prototype for the escp2 to ppm converter soon.  It's not
done yet, but, I've been using CVS for all my work for the past three years,
and now I get itchy when I'm working on something outside of CVS control.
I prefer the commit early, commit often method.

Later,

Eric

[Gimp-print-devel] Ghostscript

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

I've put Henryk "Buggs" Richter's port of the plugin to a GhostScript
driver in the repository in the gdevstp700 top level directory.  This
is version 0.1.2 of that driver.  Henryk's having some problems with
his Sourceforge account, so he asked me to do this for him.

We'll have to merge the two source bases, becasuse we don't want to
maintain two identical source trees, but we'll cross that bridge when
Henryk has his account.

Henryk, if you haven't done so already, could you please subscribe to
gim...@so...?  You can find it on
sourceforge.net->software map->printers->gimp-print->mailing lists.

-- 
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] Dynamic UI

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

   Date: Fri, 28 Jan 2000 12:59:46 +0100
   From: Andy Thaller <th...@ph...>

   Working on the canon-driver I've realized there are combinations of
   resolution,paper and ink that just don't make sense. While this
   isn't really a great insight I nonetheless wanted to discuss it
   here. When it comes to a redesign of the GUI I suggest we make it
   somewhat dynamic so it takes the valid combinations into account
   and hides the unsupported ones. Perhaps we should think about a
   mechanism in the backend to allow for this kind of flexibility.

It already is slightly dynamic; whenever the choice of printer
changes, the available paper sizes, resolution, paper type, and paper
source options are updated.  This particular problem could be solved
fairly easily, I think, but in general the UI isn't very flexible.

There's a package called pdq out there that acts as a replacement to
the lp system (at http://feynman.tam.uiuc.edu/pdq/) that looks like a
big step in the right direction for Linux/Unix printing in general,
although currently its UI support is also static.  I suspect that in
the long run they're going to want to do more UI hacking than we will,
although if we come up with a good model they might be interested in
borrowing from it.

(As far as I can tell, we're basically at the forefront of free
printing systems for Linux in general right now in a lot of ways.
What's scary is that even in terms of UI we're not giving up much, as
clunky as it is right now.)

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

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...

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

Re: [Gimp-print-devel] stc740 now understands ESC(U, but ...

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

   From: sh...@al...
   Date: Fri, 28 Jan 2000 16:28:54 +0900

   >    > In softweave mode, or microweave?
   > 
   >    I believe it was using microweave mode.
   > 
   > The really slow (1 line/pass) way?

   No, I'm sorry.  I just checked the source.  Microweave is off, if
   I'm reading it correctly.

Well, if softweave still works with the full complement of nozzles
using the old command set on new printers, I guess it's hard to argue
with success.

[Gimp-print-devel] Dynamic UI

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

Working on the canon-driver I've realized there are combinations of
resolution,paper and ink that just don't make sense. While this isn't really a
great insight I nonetheless wanted to discuss it here. When it comes to a
redesign of the GUI I suggest we make it somewhat dynamic so it takes the
valid combinations into account and hides the unsupported ones. Perhaps we
should think about a mechanism in the backend to allow for this kind of
flexibility.

Andy.

Re: [Gimp-print-devel] stc740 now understands ESC(U, but ...

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

>    > In softweave mode, or microweave?
> 
>    I believe it was using microweave mode.
> 
> The really slow (1 line/pass) way?

No, I'm sorry.  I just checked the source.  Microweave is off, if I'm reading
it correctly.

>  What I'm really concerned about is
> softweave.  Even a boat anchor will print in (pseudo)microweave mode.

Wow, you must be a better programmer than I.  I don't think I could get a
boat anchor to print, even in microweave mode.

Eric

[Gimp-print-devel] A good night's hacking

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

I did two things tonight, both of which are still a bit primitive:

1) Move the printer list from print.c to print-util.c.  The printers
   are not part of the UI, they're part of the core.  There's very
   minimal error checking in the UI now (for null printers), although
   the code *should* prevent a bogus initialization.  This was fairly
   pervasive within print.c.

2) I added typein boxes for left/top, and typeout boxes (that look
   like typein boxes because I don't know gtk very well) for
   bottom/right in the UI.  The UI is a real mess.

And now it's time for me to eat dinner, take out the garbage, and go
to sleep.

I probably won't get as much hack time for a while; my wife has been
at a meeting the past couple of days :-( so I've been able to hack :-?

Re: [Gimp-print-devel] stc740 now understands ESC(U, but ...

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

> Actually, that's precisely the problem: the matrix was getting
> absurdly large (it used to be all special cases of this kind), and
> there were too many special cases.  There are about 15 distinct
> printer models that are operationally different in some way, and about
> 10 commands.  That matrix is a bit too big for comfort already, and
> there are only going to be more printers in the future.  Not all of
> the distinct printer models differ by command set, either; some of
> them (like the 700 and EX) just differ on paper size.

For each model, you'd need about 64 bits to represent the supported command
list and likely future expansions, and another 64 should suffice for maximum
allowed paper size.  You can fit descriptions for 64 different models
in just a kilobyte.

  if (printer_commands[model]&SOME_COMMAND)
     command is supported
  else
     not

Roughly speaking, of course.

Eric

Re: [Gimp-print-devel] stc740 now understands ESC(U, but ...

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

   From: sh...@al...
   Date: Fri, 28 Jan 2000 11:09:44 +0900

   > I have no idea what these things support.  I suggest that we treat
   > them as MODEL_COMMAND_SET1 if they support 1440 and MODEL_COMMAND_SET0
   > if they don't.  Anyone have any better suggestions?

   Well, there are a lot of commands and a lot of models, but the product of
   these two is not absurdly large.

Actually, that's precisely the problem: the matrix was getting
absurdly large (it used to be all special cases of this kind), and
there were too many special cases.  There are about 15 distinct
printer models that are operationally different in some way, and about
10 commands.  That matrix is a bit too big for comfort already, and
there are only going to be more printers in the future.  Not all of
the distinct printer models differ by command set, either; some of
them (like the 700 and EX) just differ on paper size.

-- 
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] stc740 now understands ESC(U, but ...

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

> I have no idea what these things support.  I suggest that we treat
> them as MODEL_COMMAND_SET1 if they support 1440 and MODEL_COMMAND_SET0
> if they don't.  Anyone have any better suggestions?

Well, there are a lot of commands and a lot of models, but the product of
these two is not absurdly large.  You'd achieve the highest level of
flexibility by using a matrix of models and commands.  When you try to
print something, you know the model number of your printer, and you can
check to see if it implements the latest command.  If so, use it, if not,
drop back to an older version.

This way, you don't have to worry about trying to classify printers.  There
are too many special cases and I'm afraid there may be more in the future.

Eric

Re: [Gimp-print-devel] stc740 now understands ESC(U, but ...

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

   From: sh...@al...
   Date: Fri, 28 Jan 2000 10:58:14 +0900

   >    I believe they do.  Using the old Ghostscript uniprint driver for the 740
   >    produced usable about on my 750, and the programming documentation contains
   >    several versions of a few of the commands.
   > 
   > In softweave mode, or microweave?

   I believe it was using microweave mode.

The really slow (1 line/pass) way?  What I'm really concerned about is
softweave.  Even a boat anchor will print in (pseudo)microweave mode.

Re: [Gimp-print-devel] stc740 now understands ESC(U, but ...

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

>    I believe they do.  Using the old Ghostscript uniprint driver for the 740
>    produced usable about on my 750, and the programming documentation contains
>    several versions of a few of the commands.
> 
> In softweave mode, or microweave?

I believe it was using microweave mode.

Eric

Re: [Gimp-print-devel] stc740 now understands ESC(U, but ...

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

   Date: Thu, 27 Jan 2000 20:11:50 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   > MODEL_COMMAND_SET0 is the "traditional" old-style commands that all of
   > the Stylus printers support.

   > MODEL_COMMAND_SET1 is the extended commands supported by the older
   > 1440 dpi printers (the original commands will only support 720 dpi),
   > up to and including the Stylus Photo EX and 700.

   So far so good. There are however printers between SET1 and SET2:
   The 440 and 640 support most of the commands that the 740 and 900
   understand, but unfortunately not all.

   =2E.. just one moment I'm looking at my spec:

   ESC i "Transfer Raster Image" applies to 740 and 900 only
   ESC (/ "Set relative horizontal print position" is 740/900 only
   ESC ($ "Set absolute horizontal print position" is 740/900 only
   ESC (C "Set page length in defined units (extended)" is 740/900 only

   I think these are all that are different.

Yeah, then there's ESC(S, which I guess applies to the 440 and 640.  Yum.

   There are probably more issues like the ones with the 440/640. So this
   probably is not nearly as complicated as we could make it :-(

   What about the other printers not yet covered (760, 850 and 860 come
   to mind)? Do we have any idea about what command level they use?

I have no idea what these things support.  I suggest that we treat
them as MODEL_COMMAND_SET1 if they support 1440 and MODEL_COMMAND_SET0
if they don't.  Anyone have any better suggestions?

-- 
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] stc740 now understands ESC(U, but ...

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

> OK, here's my suggestion on this: we implement a new set of features
> MODEL_COMMAND_SET.  It seems like the newer printers support more
> (hopefully always) or less (hopefully never) proper supersets of the

=46rom what I understand so far this assumption is correct.=20

> older commands.  I don't want to entirely eliminate the new commands;
> I haven't calculated everything out, but I suspect that the higher
> resolutions on really long paper require the extended commands (many
> of these commands simply extend the field widths).

If you want to feed a 1200 from a roll you probably need the newest
commands.

>=20
> MODEL_COMMAND_SET0 is the "traditional" old-style commands that all of
> the Stylus printers support.
>=20
> MODEL_COMMAND_SET1 is the extended commands supported by the older
> 1440 dpi printers (the original commands will only support 720 dpi),
> up to and including the Stylus Photo EX and 700.

So far so good. There are however printers between SET1 and SET2:
The 440 and 640 support most of the commands that the 740 and 900
understand, but unfortunately not all.

=2E.. just one moment I'm looking at my spec:

ESC i "Transfer Raster Image" applies to 740 and 900 only
ESC (/ "Set relative horizontal print position" is 740/900 only
ESC ($ "Set absolute horizontal print position" is 740/900 only
ESC (C "Set page length in defined units (extended)" is 740/900 only

I think these are all that are different.

>=20
> MODEL_COMMAND_SET2 is the extended commands supported by the 740 and
> 900.
>=20
> MODEL_COMMAND_SET3 is the set supported by the 750 and 1200.
>=20
> Does this seem unnecessarily complicated?  Should we do it anyway, and
> just not implement any more of these than we can prove are necessary?

There are probably more issues like the ones with the 440/640. So this
probably is not nearly as complicated as we could make it :-(

What about the other printers not yet covered (760, 850 and 860 come
to mind)? Do we have any idea about what command level they use?

Karl Heinz

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

Re: [Gimp-print-devel] stc740 now understands ESC(U, but ...

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

   From: sh...@al...
   Date: Thu, 27 Jan 2000 22:12:09 +0900

   > Unfortunately, they keep adding more stuff to the printers, and
   > extending the commands, so it becomes a real mishmash.  One option
   > would be to try to drop back and see if the newer printers work
   > properly with the old commands.

   I believe they do.  Using the old Ghostscript uniprint driver for the 740
   produced usable about on my 750, and the programming documentation contains
   several versions of a few of the commands.

   I think in most cases the new commands only save a few bytes in transfer.
   On new command replaces several of the older ones.  At this stage,
   I don't think it's so important to include support for them.  The speed
   increase should be really marginal.

OK, here's my suggestion on this: we implement a new set of features
MODEL_COMMAND_SET.  It seems like the newer printers support more
(hopefully always) or less (hopefully never) proper supersets of the
older commands.  I don't want to entirely eliminate the new commands;
I haven't calculated everything out, but I suspect that the higher
resolutions on really long paper require the extended commands (many
of these commands simply extend the field widths).

MODEL_COMMAND_SET0 is the "traditional" old-style commands that all of
the Stylus printers support.

MODEL_COMMAND_SET1 is the extended commands supported by the older
1440 dpi printers (the original commands will only support 720 dpi),
up to and including the Stylus Photo EX and 700.

MODEL_COMMAND_SET2 is the extended commands supported by the 740 and
900.

MODEL_COMMAND_SET3 is the set supported by the 750 and 1200.

Does this seem unnecessarily complicated?  Should we do it anyway, and
just not implement any more of these than we can prove are necessary?

-- 
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] stc740 now understands ESC(U, but ...

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

   From: sh...@al...
   Date: Thu, 27 Jan 2000 22:12:09 +0900

   > Unfortunately, they keep adding more stuff to the printers, and
   > extending the commands, so it becomes a real mishmash.  One option
   > would be to try to drop back and see if the newer printers work
   > properly with the old commands.

   I believe they do.  Using the old Ghostscript uniprint driver for the 740
   produced usable about on my 750, and the programming documentation contains
   several versions of a few of the commands.

In softweave mode, or microweave?

   I think in most cases the new commands only save a few bytes in transfer.
   On new command replaces several of the older ones.  At this stage,
   I don't think it's so important to include support for them.  The speed
   increase should be really marginal.

OK, fair enough.

Re: [Gimp-print-devel] stc740 now understands ESC(U, but ...

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

> Unfortunately, they keep adding more stuff to the printers, and
> extending the commands, so it becomes a real mishmash.  One option
> would be to try to drop back and see if the newer printers work
> properly with the old commands.

I believe they do.  Using the old Ghostscript uniprint driver for the 740
produced usable about on my 750, and the programming documentation contains
several versions of a few of the commands.

I think in most cases the new commands only save a few bytes in transfer.
On new command replaces several of the older ones.  At this stage,
I don't think it's so important to include support for them.  The speed
increase should be really marginal.

Eric

Re: [Gimp-print-devel] stc740 now understands ESC(U, but ...

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

   Date: Thu, 27 Jan 2000 07:57:39 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   I'm feeling pretty lonely in this thread :-)

Not for long...

   I went through the documentation on the Epson developer site and
   found the answer to my question: The 750 and 1200 are using the
   "even newer" command set that is not understood by the 440/640/740
   and 900 printers. They are however treated the same way in the 
   plugin. I guess we have to add one more model variant to deal
   with these printers. But before we introduce a new model group,
   it probably makes sense to look at all Epson printers and see
   if there are more differences. Does anybody have or know about
   a matrix that lists all printers and the commands they support?

Unfortunately, they keep adding more stuff to the printers, and
extending the commands, so it becomes a real mishmash.  One option
would be to try to drop back and see if the newer printers work
properly with the old commands.  It's possible that the new printers
will work in back compatibility mode with the old commands, but won't
be able to softweave or something.

So I guess we have yet another model variant here...

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

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...

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

Re: [Gimp-print-devel] stc740 now understands ESC(U, but ...

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

Robert L Krawitz <rl...@al...> said: 

>    Date: Wed, 26 Jan 2000 21:02:29 -0500
>    From: Karl Heinz Kremer <kh...@kh...>
> 
>    =2E.. OK, here is more information: There is an extra instance of
>    ESC(S on line #815 in print-escp2.c.
> 
> Yuk!  It was at line 810 in my source.
> 					
> 					This only outputs the command,
>    but does not print any parameters. When I remove this command I
>    am having problems with ESC(c. The documentation I have lists
>    four parameters for ESC(c, the code however uses eight. Is it
>    possible that the MODEL_VARIABLE_4 printers use different types
>    of "Set page format" commands? Which printers do use eight=20
>    parameters?
> 
> I found that in 750 output.  It's possible that it's specific to the
> 750 and/or 1200.  I just took a guess at what the other four bytes
are
> (that instead of two shorts, they're two ints), but it's entirely
> likely I'm wrong.  Try changing back to the four parameter version
> (remove the extra null bytes) and see if it works?

I just answered my own question in another mail to the list. You
are right that this is specific to the 750/1200. 
I'll see what I can to tonight. 

Karl Heinz

Re: [Gimp-print-devel] Wow!

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

> Is a spectrometer really needed? Wouldn't a (more or less) calibrated scanner
> do?

The short answer is no.

This is from the Color FAQ:

  13.  DOES MY SCANNER USE THE CIE SPECTRAL CURVES?

  Probably not. Scanners are most often used to scan images such as color
  photographs and color offset prints that are already "records" of three
  components of color information. The usual task of a scanner is not
  spectral analysis but extraction of the values of the three components that
  have already been recorded. Narrowband filters are more suited to this task
  than filters that adhere to the principles of colorimetry.

  If you place on your scanner an original colored object that has
  "original" SPDs that are not already a record of three components, chances
  are your scanner will not very report accurate RGB values. This is because
  most scanners do not conform very closely to CIE standards.

> Of course it wouldn't yield full spectral information but how much of it is
> really needed for color management?

Excerpted from question 24:

  Practical photographic dyes and offset printing inks have spectral
  absorption curves that overlap significantly. Most magenta dyes absorb
  mediumwave (green) light as expected, but incidentally absorb about half
  that amount of shortwave (blue) light. If reproduction of a color, say
  brown, requires absorption of all shortwave light then the incidental
  absorption from the magenta dye is not noticed. But for other colors, the
  "one minus RGB" formula produces mixtures with much less blue than
  expected, and therefore produce pictures that have a yellow cast in the mid
  tones. Similar but less severe interactions are evident for the other pairs
  of practical inks and dyes.

  Due to the spectral overlap among the colorants, converting CMY using the
  "one-minus-RGB" method works for applications such as business graphics
  where accurate color need not be preserved, but the method fails to
  produce acceptable color images.

  Multiplicative mixture in a CMY system is mathematically nonlinear, and the
  effect of the unwanted absorptions cannot be easily analyzed or
  compensated. The colors that can be mixed from a particular set of CMY
  primaries cannot be determined from the colors of the primaries
  themselves, but are also a function of the colors of the sets of
  combinations of the primaries.

> Could someone please post some URLs where to
> get basic information?

Start here:

http://www.inforamp.net/~poynton/ColorFAQ.html

Eric

Re: [Gimp-print-devel] Release strategy

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

   From: sh...@al...
   Date: Thu, 27 Jan 2000 16:27:42 +0900

   > 1) The current makefile situation is basically silly.  It's just the
   >    generated makefiles, plus a handcrafted one I threw together.  So
   >    we probably need some kind of configure script (which seems like
   >    overkill in a way, but maybe this project isn't so tiny after all),
   >    or the like.

   I'll see what I can do here.  I'll try to upload a conf script along with
   the escp2 to pnm converter.  Expect something Sunday night JST, at the latest.

Thanks.

   > 4) Decide if we want to ship any prepackaged binaries (the obvious is
   >    Red Hat RPM's, but one of our group who's having some problems with
   >    his Sourceforge account but who wants to join, Daniel Egger, works
   >    for SuSE, and I run SuSE at home, so we might have some controversy
   >    there :-) )

   Don't forget Debian packages!

That's part of the reason I'm not convinced we want to distribute
stuff in precompiled binary form -- too many corner cases, and too
much risk of offending someone.  Of course, if you want to build the
Debian packages :-)

-- 
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] stc740 now understands ESC(U, but ...

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

I'm feeling pretty lonely in this thread :-)

Karl Heinz Kremer <kh...@kh...> said: 

> On Wed, Jan 26, 2000 at 08:40:05AM -0500, Karl Heinz Kremer wrote:
> > Here is what I found out late last night: With the latest CVS
> > version my Epson stc740 handles the set unit command correctly,
> > but still produces only blank pages. I looked at the ESC/P code
> > and it looks like there is an extra byte after the ESC(S command.
> > I was too tired at that time to actually find the problem in 
> > the source code, so this either has to wait until tonight, or
> > until somebody else will have a chance to look at it.
> 
> ... OK, here is more information: There is an extra instance of
> ESC(S on line #815 in print-escp2.c. This only outputs the command,
> but does not print any parameters. When I remove this command I
> am having problems with ESC(c. The documentation I have lists
> four parameters for ESC(c, the code however uses eight. Is it
> possible that the MODEL_VARIABLE_4 printers use different types
> of "Set page format" commands? Which printers do use eight 
> parameters?
> 

I went through the documentation on the Epson developer site and
found the answer to my question: The 750 and 1200 are using the
"even newer" command set that is not understood by the 440/640/740
and 900 printers. They are however treated the same way in the 
plugin. I guess we have to add one more model variant to deal
with these printers. But before we introduce a new model group,
it probably makes sense to look at all Epson printers and see
if there are more differences. Does anybody have or know about
a matrix that lists all printers and the commands they support?

Karl Heinz

Re: [Gimp-print-devel] stc740 now understands ESC(U, but ...

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

   Date: Wed, 26 Jan 2000 21:02:29 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   =2E.. OK, here is more information: There is an extra instance of
   ESC(S on line #815 in print-escp2.c.

Yuk!  It was at line 810 in my source.
					
					This only outputs the command,
   but does not print any parameters. When I remove this command I
   am having problems with ESC(c. The documentation I have lists
   four parameters for ESC(c, the code however uses eight. Is it
   possible that the MODEL_VARIABLE_4 printers use different types
   of "Set page format" commands? Which printers do use eight=20
   parameters?

I found that in 750 output.  It's possible that it's specific to the
750 and/or 1200.  I just took a guess at what the other four bytes are
(that instead of two shorts, they're two ints), but it's entirely
likely I'm wrong.  Try changing back to the four parameter version
(remove the extra null bytes) and see if it works?

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