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