gimp-print-devel

[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

Re: [Gimp-print-devel] Wow!

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

sh...@al... wrote:

> Actually a spectrometer, if I had one, would give much more information.
>
> Unfortunately, with subtractive color systems it's not possible to know,
> given the colors of the inks, what the colors of the mixtures will be.
> You need the whole spectrograph in order to accurately predict this.  I don't
> have that information.

Is a spectrometer really needed? Wouldn't a (more or less) calibrated scanner
do? Of course it wouldn't yield full spectral information but how much of it is
really needed for color management? Could someone please post some URLs where to

get basic information?

Andy.

Re: [Gimp-print-devel] Release strategy

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

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

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

Eric

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

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

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=20
> the source code, so this either has to wait until tonight, or
> until somebody else will have a chance to look at it.

=2E.. 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=20
parameters?

Karl Heinz

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

[Gimp-print-devel] Oh yeah, Federico's message...

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

Date: Tue, 25 Jan 2000 19:17:31 -0500
From: Federico Mena Quintero <fed...@he...>
To: gim...@sc...
In-reply-to: <200...@ce...> (message from Marc Lehmann
	on Tue, 25 Jan 2000 21:00:45 +0100)
Subject: Re: Speaking of additional plug-ins

>  > For the record, I think a plug-in CVS tree independent of Gimp is a good idea.
>  
>  "Let's focus, people!"
[snip]
>  > The issue is: who has the time? Without people, good ideas remain abstract.
>  
>  I have no time, but I would nevertheless devote part of on merges between
>  the two cvs trees. I could also set up a cvs server, but I firmly believe
>  that it should be related to the gimp.org domain, and I would first have
>  to ask my "boss" wether abusing a machine at the university would be ok
>  (this is a space issue).

<delurk>

People should feel free to ask for a CVS account on the cvs.gnome.org
box.  If they have something cool they are working on for the GIMP, we
can certainly give them access, provided they are willing to follow
the standard GNOME CVS etiquette.

As far as the GIMP is concerned, people could maintain their own
experimental plug-ins in little CVS modules and later, when the
plug-in is Done(tm), they could ask a CVS maintainer to physically
move it to the main GIMP module.  Or it could be linked as a virtual
module, which also is a nice solution.  This way you can have branches
for particular plug-ins.

In particular, I would love to see the fantastic Print plug-in on the
GNOME CVS :-)  Of course, that is up to Robert to decide.  If there is
anything the CVS maintainers can do to make Robert's life easier, I'd
love to hear about it.

</delurk>

  Federico

...and my response...

Date: Tue, 25 Jan 2000 20:51:06 -0500
From: Robert L Krawitz <rl...@al...>
To: fed...@he...
CC: gim...@sc...
In-reply-to: <200...@lo...>
	(fed...@he...)
Subject: Re: Speaking of additional plug-ins

   Date: Tue, 25 Jan 2000 19:17:31 -0500
   From: Federico Mena Quintero <fed...@he...>

   In particular, I would love to see the fantastic Print plug-in on the
   GNOME CVS :-)  Of course, that is up to Robert to decide.  If there is
   anything the CVS maintainers can do to make Robert's life easier, I'd
   love to hear about it.

Thank you :-)  Actually, this gives me an opening for a couple of
other thoughts I have kicking around and a bit of soapboxing.  (and
BTW my wife says hi to all my net buddies, and politely inquires when
she can have her husband back :-) )

Actually, Olof put 3.0.3 in the Gimp CVS repository, and I've sent him
3.0.5 (the latest stable version).  At this point, 3.0 belongs with
the Gimp.  3.1 (which is what we're working on over at SourceForge --
we have 5 people signed up, and there are a couple more I'm waiting
for them to create accounts) doesn't.

A quick aside as to why I chose Sourceforge for this: Sourceforge
provides a complete hosting solution.  In addition to a CVS repository
(not just a CVS directory, it's an entire repository for each
project), they provide message forums, mailing lists, shell accounts,
backups, web hosting, a complete secure web-based administration
interface, basically soup to nuts.  I can decide who to accept as a
developer (or project administrator) and not need to worry if that
person's acceptable to the GNOME folks.  I'm still learning about it
(it's a really capable system, and VA is putting serious resources
behind it including what amounts to a help desk!), but we're
attracting a lot of attention in a hurry and I'm recruiting good
developers.  I don't want to split the effort with 3.1.

Basically, 3.0.5 is the last release I'm planning to make on the 3.0
(stable) branch, unless we have serious bugs or VERY low-risk features
from 3.1.  This is the version I'd like to see go into the 1.2 feature
freeze.  It's capable enough so that it will be useful to a lot of
people, while it's also received a decent amount of testing and we at
least know what the problems are with it, by and large.  So I have no
problem putting 3.0.5 in there.

<soapbox>
There are a number of very important changes that we're looking at for
3.2 (i. e. that will be on the 3.1 development line) that will have
important ramifications for its continued existence as a Gimp plugin.
The most important one is that we actually want to rip out the guts
altogether, put them into various Ghostscript and/or CUPS drivers (no
reason we can't do both, maybe with some kind of libprint, although
Ghostscript seems to be very hostile to anything remotely resembling a
decent architecture), and make the Print plugin merely be a glue layer
between the Gimp and the Linux printing system.

We actually have a prototype of the first half of this already --
Henryk Richter converted the Epson piece of the plugin (plus the
rendering engines) into a Ghostscript driver.  It has some residual
problems, mostly related to various static variables, but he reports
that it works just fine otherwise.  This is actually very exciting
news.  Henryk has been entirely too modest about it :-)

We'll release a Ghostscript driver based on 3.0.5 when we have the
static variable issues ironed out, and if that goes well we'll do
another release based on 3.2 (or some other stable intermediate point
if we find that the new Epson printers go well, since that will
probably be a big requirement for a lot of folks, and it's important
to be able to compete with Windows and the Mac on print quality).
</soapbox>

<wayfaroffinthefuture>
So what's basically going to happen is that we'll eventually (I'd like
to say 3.2, but that's not realistic for reasons I'll discuss below)
remove everything but the Postscript driver and the front end (GUI)
from the print plugin, and then that will stabilize.

The limitation here is that Ghostscript/lpd doesn't provide a way to
pass information about a printer's capabilities back to a front end.
Without this, we really don't have a way for the plugin (or for ANY
application print dialog, which is the real point here) to give the
user any reasonable way to set options.  For anything where output
quality matters (and I can't think of too many things where it's more
important than for the Gimp), this is not acceptable.  The Epson
Stylus Photo EX is a very fine printer (and the newer ones are even
better), but there are still some important choices to be made.
1440x720 highest quality output is great, but if you want a quick
proof it's too slow.  If you're using Luminos archival inks, you need
to tune the colors, and so forth.

So unfortunately, I think that the best we'll be able to do in 3.2 is
to have a couple of drivers using the same source base, with different
front ends.  But I want to be careful about tying the whole thing too
tightly to the Gimp, because that won't solve the real problem.  I
suppose if people see really high quality output from the Gimp and
then wonder why they can't get their other applications to do the same
thing they'll start to complain, but I want to be well at work on the
solution by the time this starts.  I suspect that that's going to mean
GNOME and KDE, although I'd like to see something even below that
level.
</wayfaroffinthefuture>

There is a script around to build a Gimp plugin, but it seems to be
targeted at simple single-source-file plugins.  I don't really want to
go through the whole hassle of doing a full fledged configure script
for it, though, because that seems a bit much for something that's
"just" a plugin.  I agree very much with the idea of a separate plugin
tree, though.  The best way to determine if a plugin architecture is
good is if it's really possible to keep the plugins separate from the
source (at least at the source level, if not at the end user level)
and to be able to build new plugins easily, on demand.

Actually, on further thought something that might be useful would be a
way to move useful development snapshots from Sourceforge to the
plugin tree, whether that's on gimp.org or gnome.org (in other words,
do 3.1.x releases to the tree, to allow people to experiment with
different versions).

-- 
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] Release strategy

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

I'm a bit undecided about what our best release strategy might be, so
I'd like to ask for some opinions here.

We're getting some attention on gimp-developer (in particular, the
note I'm enclosing at the end of this one).  I happen to like
Sourceforge as a hosting service, but that's not the point -- Federico
likes this thing.

Currently, 3.0.3 is in the Gimp CVS tree, and I've asked Olof to put
3.0.5 in there.  My general impression is that 3.0.5 (or any future
bug release based on that) is what will go out with Gimp 1.2.  Of
course, if that gets delayed enough, and there's really heavy demand
for newer printers and our code's in good shape, we might have 3.2
ready, but I kinda hope not (in other words, I hope that the Gimp 1.2
goes out soon).

However, I think that once things stabilize a bit more -- we get at
least some of the newer Epson printers working, and/or the Canon
stuff, or something else significant -- that we should do a 3.1
release as quickly as practicable.  This will follow the usual Linux
kernel convention; odd-number minor versions are development,
even-numbered ones are stable.  I'd like to have something we can put
up here, and announce on Freshmeat and Appwatch, and start getting
some more feedback.  However, in order for that to be useful, we need
some stuff:

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.

2) There's no significant user level documentation: what the various
   controls do, how to build it, tuning it for various printers, how
   to support a new printer maybe....  The README that I wrote is a
   joke that I should be ashamed to be associated with :-)

3) Web site: the current situation (my personal page) is purely a
   stopgap.  Sourceforge provides a very nice web hosting environment,
   with at least PHP.  I might need to give someone the appropriate
   bits; I'll take as an action item learning how to do that (give
   somebody the bits).

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

Right now, it looks like the following people are working on the
following things:

* Eric Sharkey: escp2 emulator (a "soft printer" of a kind?)

* Nicholas Piper's interested in working on the web site.  That's one
  of the release tasks.

* Karl Heinz Kremer is looking at debugging the Epson Stylus 740
  driver (which will give us the key to a number of other current
  generation printers).

* Andy ??? is working on Canon support.

* Me -- ???  I've been doing odds and ends, working on the
  stc440/640/740/900 and stp750/1200 support and such.

So any volunteers?

-- 
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] Undoing all your hard work

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

> Double check that you're running a recent version of cvs (I'm running
> 1.10.6 with client/server),

I have 1.10.7.

> and that CVS_RSH is set to the correct version of ssh.

/usr/bin/ssh

> The version of ssh I'm using is:
> 
> $ ssh -v
> SSH Version 1.2.27 [i686-unknown-linux], protocol version 1.5.
> Standard version.  Does not use RSAREF.

scribe% ssh -V
SSH Version OpenSSH-1.2.1, protocol version 1.5.
Compiled with SSL.
 
> But I somehow doubt that that's the problem.  It looks like it thinks
> you're actually trying to log in to cvs.gimp-print.sourceforge.net,
> rather than just talk to a cvs server.  You might try asking the
> sourceforge people if they can help you, if these suggestions don't do
> the trick.

It's strange, because I use CVS with a nearly identical setup for work,
and I don't have any problems.  Of course, the server is different...

I'll contact SF.

Eric

Re: [Gimp-print-devel] Wow!

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

> >     Color             L       A       B
> >     -------------  ------  ------  ------
> >     White           90.71    1.12   -4.37
> >     Cyan            52.40  -26.85  -39.29
> >     Magenta         55.56   61.60   -3.79
> >     Yellow          84.35    2.77   68.90
> >     Black           27.67    1.30   -0.76
> >     Light Cyan      67.69  -28.57  -31.96
> >     Light Magenta   66.63   46.71  -11.90
> > 
> 
> Isn't this information that could also be gathered using a spectrometer?

Actually a spectrometer, if I had one, would give much more information.

Unfortunately, with subtractive color systems it's not possible to know,
given the colors of the inks, what the colors of the mixtures will be.
You need the whole spectrograph in order to accurately predict this.  I don't
have that information.

Eric

Re: [Gimp-print-devel] Undoing all your hard work

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

   From: sh...@al...
   Date: Thu, 27 Jan 2000 11:28:05 +0900

   Last night I started work on a printer simulator.  Basically, it's
   an escp2 to pnm translator.  It's basically along the lines of parse-escp2,
   except in C and producing output which can be viewed on screen.

   The resulting files will be huge, frankly, but this isn't really an end
   user tool.  I think it could be useful for sanity checking driver output
   and also for testing new dithering algorithms.

That sounds really, really useful.  Actually, for testing dithering
algorithms this kind of thing could be useful with any printer (just
print it out with an Epson driver and display the result).

   Of course, it wouldn't be a comprehensive or accurate test, but it should
   pick up major screwups.  It's also handy if you don't actually have the
   printer around.

Or if you want to save on ink/paper bills, or you have clogged jets,
like I do :-)

   I expect to have it ready within a day or two, barring unforeseen
   circumstances, but so far I have not been able to access the repository
   except as an anonymous user.  Anyone else seen this problem?

   scribe% cvs -z3 -dsh...@cv...:/cvsroot/gimp-print co print
   sh...@cv...'s password: 
   cvs checkout: warning: unrecognized response `' from cvs server
   cvs checkout: warning: unrecognized response `Welcome to cvs1.sourceforge.net' from cvs server
   cvs checkout: warning: unrecognized response `' from cvs server
   cvs checkout: warning: unrecognized response `This is a restricted Shell Account' from cvs server
   cvs checkout: warning: unrecognized response `You cannot execute anything here.' from cvs server
   cvs checkout: warning: unrecognized response `' from cvs server
   cvs [checkout aborted]: end of file from server (consult above messages if any)

   I'm using OpenSsh, if that makes a difference.

Double check that you're running a recent version of cvs (I'm running
1.10.6 with client/server), and that CVS_RSH is set to the correct
version of ssh.  The version of ssh I'm using is:

$ ssh -v
SSH Version 1.2.27 [i686-unknown-linux], protocol version 1.5.
Standard version.  Does not use RSAREF.

But I somehow doubt that that's the problem.  It looks like it thinks
you're actually trying to log in to cvs.gimp-print.sourceforge.net,
rather than just talk to a cvs server.  You might try asking the
sourceforge people if they can help you, if these suggestions don't do
the trick.

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