gimp-print-devel

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...endle> (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: <200001260017.TAA06941@localhost.localdomain>
	(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 -ds...@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

Re: [Gimp-print-devel] Wow!

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

   From: sh...@al...
   Date: Thu, 27 Jan 2000 10:53:04 +0900

   > That's quite true.  I should think that unless they claim copyright
   > over the output files, or that someone is not allowed to give someone
   > else an output file, that it would be a bit harder for them to go
   > after someone for disassembling the output file.

   I don't think so.  Although you are disassembling the output, and not
   disassembling the driver, you are reverse engineering the driver not the
   output.  The output is already understood.

No, the output isn't understood yet.  You don't care how the driver
operates; it's a matter of how the printer operates.  Consider that
there are free programs around that can read Word or Excel files and
nobody has gone after them.

Until and unless someone consults a competent lawyer in the US, I
would like everyone to observe the following principles:

1) Any specific information obtained from someone you have reason to
   believe has signed a relevant NDA, and that that information is
   likely to be covered by the NDA, should not be used here.  That
   definitely includes CIE values, which are about as important a
   trade secret as a printer manufacturer would have.  If the
   information is merely of the form "Page X of the publicly available
   programming manual covers this" that's fine.  If it's a gray area,
   stay away.  In the particular case, I do not want the CIE values
   for the Epson inks used in the program.  Whether you're legally in
   the clear or not notwithstanding (and I don't think you are,
   necessarily), violating an NDA is simply a dishonorable thing to
   do.

2) Any such information obtained by independent methods (e. g. by
   means of a spectrometer, or if someone who you have no reason to
   believe is under NDA gives you values that s/he says are obtained
   by independent means) is legitimate.  But don't try to cut corners
   here.

3) Information obtained by examination of output (either output files
   or actual printed output) can be used as freely as you consider
   appropriate.  If you want to try to reverse engineer the dithering
   algorithms (beyond just the command sequences required), and a
   friend gives you a printout, and you use a loupe to inspect the
   paper, that's completely kosher (I'd have real trouble believing
   that your friend is violating any agreement by giving you a printed
   photo that s/he has rights to, and so ordinary copyright applies:
   if you own the photo, you can do as you please; if someone else
   owns the rights to the photo, you need permission from that
   person).

4) Information obtained by disassembling code or any files supplied by
   the manufacturer is out of bounds.

If someone can document that disassembling output files generated from
data that you legally possess for purposes of interoperability has
been found in violation of anything, I will reconsider (3).  Beyond
that, it's not a matter of legalities or not, it's a matter of what I
consider an honorable thing to do.

I will discuss this in personal email, but I do not want further
debate on it on the list unless someone has actual expert legal
opinion to offer.  I want to concentrate on the driver, not on the
law.

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

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

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.

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.

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

Eric

Re: [Gimp-print-devel] Wow!

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

> That's quite true.  I should think that unless they claim copyright
> over the output files, or that someone is not allowed to give someone
> else an output file, that it would be a bit harder for them to go
> after someone for disassembling the output file.

I don't think so.  Although you are disassembling the output, and not
disassembling the driver, you are reverse engineering the driver not the
output.  The output is already understood.  Since the driver is licensed
to you under a license which forbids reverse engineering the driver (a
much more broad term than disassembly or decompilation), such activity
terminates the license.  At this point you no longer have a license for
the driver, so any further use of the driver is a violation of copyright.

At least, that's what Epson might say.

I suppose, in theory you could print out a whole bunch of test patterns,
delete the driver, and then begin the reverse engineering.  Since you've
legally downloaded the driver, used the driver to produce output files,
and then terminated your license by deleting the copyrighted software, you
can't be held for copyright violation, since at the time you possessed the
software you had a valid license, and at the time you reverse engineered
it you did not have a copy.

There may be a loophole in that loophole, though.

Eric

Re: [Gimp-print-devel] Color Management [Was: Re: Wow!]

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

   Date: Wed, 26 Jan 2000 16:18:53 +0100
   From: Andy Thaller <th...@ph...>

   The color pattern I'm printing contains 8 intensity levels each for
   CMYKRGB. Is this amount of colors sufficient for producing
   color-transfer information or would we need more? Are there any
   standard methods for reverse engineering color-management data? Any
   tools for extracting the data from the print files? I've started to
   work on one for the canon stuff but would happily use an existing
   one ;-)

Try grabbing http://www.tiac.net/users/rlk/colors.tif.  This is a
color sweep pattern that I found extremely 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!

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

   From: sh...@al...
   Date: Thu, 27 Jan 2000 01:30:03 +0900

   > I want to be very careful about information obtained from
   > questionable sources, particularly this kind of very specific
   > info.  I don't have a problem with people using information
   > reverse engineered out of print files.  For example, if you print
   > a uniform color patch from Windows, and then disassemble the
   > generated output to determine how much of each color was used,
   > that's fine by me.

   What's fine by you is largely irrelevant, however.  What matters is
   what's fine by Epson (which determines if a suit gets filed) and
   what's fine by the courts (which decide who wins the suit).

That's quite true.  I should think that unless they claim copyright
over the output files, or that someone is not allowed to give someone
else an output file, that it would be a bit harder for them to go
after someone for disassembling the output file.

   I downloaded their current W95 driver a few days ago, and I read
   the click license before downloading it.  It specifically states
   that reverse engineering is not allowed.  Although I did download
   it, I have not installed it, specifically because of this very
   problem.

I don't want to touch the Epson drivers for exactly this reason.  I
haven't downloaded it or looked at any license.

   > Likewise, the spectrometer idea.  If someone under NDA (who you
   > had good reason to believe was under NDA) told you something that
   > you had good reason to believe was under NDA (e. g. he or she
   > told you), then stay away from it.

   Why?  If someone is under NDA and tells someone else who is not
   under NDA, then those people under NDA are not liable for anything.
   It's the same issue as was raised in the DVD case when the MPAA
   tried to claim CSS was a trade secret.  They could get the guy who
   cracked it, but, once it was given to "an innocent" it was no
   longer protected.  The MPAA quickly changed their position, saying
   that the code would promote further copyright violations.  I can't
   see how Epson could claim that about the ink colors.

The MPAA still seems to be trying to claim trade secret violation,
last I checked.

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

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

   Date: Wed, 26 Jan 2000 16:32:22 +0000
   From: Nicholas Piper <pc...@in...>

   I can put in a few hours for some web pages over the next
   few days if wanted.

   I'd *like* to use Zope, but I doubt that anyone has access to a zope
   server ? Maybe someone has a machine that could host a zope server ?

   (I realise zope would be overkill, but I'm trying to collect
   real-world experience with it).

   The other options are PHP or HSC (or some other preprocessor).

Sourceforge supports at least php; I'm not sure what else.

[Gimp-print-devel] webpages

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

I can put in a few hours for some web pages over the next
few days if wanted.

I'd *like* to use Zope, but I doubt that anyone has access to a zope
server ? Maybe someone has a machine that could host a zope server ?

(I realise zope would be overkill, but I'm trying to collect
real-world experience with it).

The other options are PHP or HSC (or some other preprocessor).

Anyone have any comments/feelings ?

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

Re: [Gimp-print-devel] Wow!

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

>    I won't mention how I got this information since it's not available in
>    Epson level 1 programming documents.  I normally like to give credit where
>    credit is due, but, in this case, it may be better not to.
> 
> I want to be very careful about information obtained from questionable
> sources, particularly this kind of very specific info.  I don't have a
> problem with people using information reverse engineered out of print
> files.  For example, if you print a uniform color patch from Windows,
> and then disassemble the generated output to determine how much of
> each color was used, that's fine by me.

What's fine by you is largely irrelevant, however.  What matters is what's
fine by Epson (which determines if a suit gets filed) and what's fine by
the courts (which decide who wins the suit).

I downloaded their current W95 driver a few days ago, and I read the click
license before downloading it.  It specifically states that reverse engineering
is not allowed.  Although I did download it, I have not installed it,
specifically because of this very problem.

> Likewise, the spectrometer
> idea.  If someone under NDA (who you had good reason to believe was
> under NDA) told you something that you had good reason to believe was
> under NDA (e. g. he or she told you), then stay away from it.

Why?  If someone is under NDA and tells someone else who is not under NDA,
then those people under NDA are not liable for anything.  It's the same
issue as was raised in the DVD case when the MPAA tried to claim CSS was
a trade secret.  They could get the guy who cracked it, but, once it was
given to "an innocent" it was no longer protected.  The MPAA quickly changed
their position, saying that the code would promote further copyright
violations.  I can't see how Epson could claim that about the ink colors.

Anyway, his or her words justifying this release were "you can get these
yourself with the right equipment, so they aren't strictly covered by the NDA",
but it's enough of a grey area that I don't feel comfortable mentioning just
who he or she is.

But, I think using this information is legally safer than printing color
blocks with the windows driver.  I'm not a lawyer, though.

Two days ago I sent a message to Epson tech support asking for clarifications
on what activities would likely result in legal retaliation.  Other than the
auto-responder, I have not heard back from them yet.
  
Eric

[Gimp-print-devel] Color Management [Was: Re: Wow!]

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

Robert L Krawitz wrote:

> I want to be very careful about information obtained from questionable
> sources, particularly this kind of very specific info.  I don't have a
> problem with people using information reverse engineered out of print
> files.  For example, if you print a uniform color patch from Windows,
> and then disassemble the generated output to determine how much of
> each color was used, that's fine by me.  Likewise, the spectrometer
> idea.  If someone under NDA (who you had good reason to believe was
> under NDA) told you something that you had good reason to believe was
> under NDA (e. g. he or she told you), then stay away from it.

I'm currently disassembling a bunch of canon-print files to get the canon part
of the print plugin working.

The color pattern I'm printing contains 8 intensity levels each for CMYKRGB. Is
this amount of colors sufficient for producing color-transfer information or
would we need more? Are there any standard methods for reverse engineering
color-management data? Any tools for extracting the data from the print
files? I've started to work on one for the canon stuff but would happily use an
existing one ;-)

Andy

Re: [Gimp-print-devel] Wow!

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

   From: sh...@al...
   Date: Wed, 26 Jan 2000 13:41:13 +0900

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

   I won't mention how I got this information since it's not available in
   Epson level 1 programming documents.  I normally like to give credit where
   credit is due, but, in this case, it may be better not to.

I want to be very careful about information obtained from questionable
sources, particularly this kind of very specific info.  I don't have a
problem with people using information reverse engineered out of print
files.  For example, if you print a uniform color patch from Windows,
and then disassemble the generated output to determine how much of
each color was used, that's fine by me.  Likewise, the spectrometer
idea.  If someone under NDA (who you had good reason to believe was
under NDA) told you something that you had good reason to believe was
under NDA (e. g. he or she told you), then stay away from it.

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

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

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

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

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

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.

Karl Heinz

Re: [Gimp-print-devel] Wow!

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

Robert L Krawitz <rl...@al...> said: 
[ ... ]
> I've tried contacting Epson tech support; thus far it's dropped into
a
> black hole.

I'm also still waiting for a response from Epson. I just hope that
this HP/VA announcement is a wakeup call for the rest of the
manufacturers. By now they should now that if you advertise 
Linux support your stock price goes through the roof :-)

Karl Heinz

Re: [Gimp-print-devel] Wow!

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

   Date: Wed, 26 Jan 2000 07:09:03 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   In gerneral: Did you see the news regarding HP and VA working together
   to improve the printing under Linux. This is good news, and maybe this
   could also be the trigger to get Epson and other manufacturers on board.

That's very interesting.  I know SuSE is also working with one of the
major printer vendors, but its name escapes me (either Lexmark or
Canon, I think).  So maybe we should see if anyone at Red Hat or
Caldera might have contacts at Epson.

   Does anybody know any addresses (email or snailmail) where we could
   complain/suggest about Linux support.

I've tried contacting Epson tech support; thus far it's dropped into a
black hole.

Is anyone here any good at web site development?  Having a more
professional-looking web site would help when contacting vendors.

-- 
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: Wed, 26 Jan 2000 13:41:13 +0900

   It remains to be seen whether the "correct" color transforms will actually
   improve results over more trial and error methods.  Reading the documents
   on color transforms, it seems that there is still a lot of trial and
   error involved in color science.

Then there's the whole matter of paper types, and third party inks,
and all that.  720 DPI on plain paper isn't what I consider a terribly
interesting case for the Gimp (it's a very interesting case for
*business* graphics, and since we're looking at generalizing this, we
do have to take that into account).  Even proofing from the Gimp will
normally be on higher quality paper.  I think.

   > 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 doesn't sound hard to fix.

It shouldn't be too bad; what's a bit tricky is the sheer number of
ratios there are and finding all of the places where they're
implicitly hidden (such as the conversion between CMY and K).

   > Interested in this stuff?

   Yes.  I'll take a crack at it later this evening.

   Do you have any guidelines for CVS commissions?  I gather that
   since I'm now a registered developer, I have commission privileges,
   but some project leaders I know prefer to approve each patch
   individually before commission.

Yes, all the registered developers do have write access to the
repository.

At this point in time I'd like to be fairly free about it.  It's an
absolute given that it must compile without any new warnings.  If you
have a printer that you can test on, please conduct some kind of
sanity test.  When we get closer to a release I'd like to tighten
things up a bit (each commit should be reviewed by at least one other
developer), but it's too early for that yet.  I do have significant
release engineering experience, and I'm not worried about keeping this
sane.

Late in the release cycle, normal policy would be that each commit
should be preceded by a full test run.  For obvious reasons, that's
not practical here, so we'll have to improvise.  Right now there are
only about five of us, and I think we can keep things under control.

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

On Wed, Jan 26, 2000 at 01:41:13PM +0900, sh...@al... wr=
ote:
>=20
>     (for 720 DPI on plain paper)
>=20
>     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
>=20
> (Note to Epson Corporate types trolling the net:  The message I wrote
> earlier listing the people I had contacted on this topic was *not* a
> complete list. (Ok, this DVD case is making me a little paranoid...))
>=20

Isn't this information that could also be gathered using a spectrometer?
If I just print certain color and meassure, this should give me all
the tables for all the printers that I have access to.

In gerneral: Did you see the news regarding HP and VA working together
to improve the printing under Linux. This is good news, and maybe this
could also be the trigger to get Epson and other manufacturers on board.

Does anybody know any addresses (email or snailmail) where we could
complain/suggest about Linux support.

Karl Heinz

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

Re: [Gimp-print-devel] Wow!

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

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

I won't mention how I got this information since it's not available in
Epson level 1 programming documents.  I normally like to give credit where
credit is due, but, in this case, it may be better not to.

Here are the numbers:

    (for 720 DPI on plain paper)

    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

(Note to Epson Corporate types trolling the net:  The message I wrote
earlier listing the people I had contacted on this topic was *not* a
complete list. (Ok, this DVD case is making me a little paranoid...))

It remains to be seen whether the "correct" color transforms will actually
improve results over more trial and error methods.  Reading the documents
on color transforms, it seems that there is still a lot of trial and
error involved in color science.

> 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 doesn't sound hard to fix.

> Interested in this stuff?

Yes.  I'll take a crack at it later this evening.


Do you have any guidelines for CVS commissions?  I gather that since I'm now
a registered developer, I have commission privileges, but some project
leaders I know prefer to approve each patch individually before commission.

Eric

[Gimp-print-devel] More stuff

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

A combination of a heavy snowstorm and a flaky VPN-type connection to
work let me get some stuff done.  Here are the latest goodies:

1) Some improvements to the newer Epson printers.  There's actually
   some hope that the 440, 640, 740, 900, 750, and 1200 will print.

2) Generalized page sizes.  Rather than having each printer work from
   a fixed list, I put a list of paper sizes in print-util, and the
   drivers query this database.

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