From: "Robin Rowe" <[EMAIL PROTECTED]>
Date: Wed, 23 Oct 2002 18:47:54 -0700
> This can't really be lead from the print side. We'll have no problem
> with 16-bit and CMYK (although we don't currently support 16-bit RGB),
> but the GIMP side needs to spec an API for it.
Hi. Thanks for the clarification.
What I meant was "print" in the magazine/book publishing sense, not
gimp-print. A developer knowledgable in the print side of the business would
help in building the right 16-bit CMYK stuff.
OK. I should note that I'm basically only familiar at all with
inkjets; other printers have very different characteristics.
With a little more digging I discovered some email discussion with John
Culleton in the archives describing using netpbm pnmtotiffcmyk
(http://sourceforge.net/projects/netpbm/) for command line conversion.
> tifftopnm RGB.tiff | pnmtotiffcmyk > CMYK.tiff
Looking further I find pnmtotiffcmyk
(http://sourceforge.net/projects/netpbm/) and CMYKTiff
(http://www.acooke.org/jara/cmyktiff/). In theory someone could take that
into a Film Gimp plug-in pretty easily, and that could output to gimp-print.
Is that what we need?
I don't think this is the right approach for production, although for
prototyping it may be of use. In order to be really useful as CMYK,
it's necessary for all of the channels to be independently editable
(e. g. to get a solid black on some printers it's necessary to use
CMY+K; K alone won't do it). That isn't the case with this package.
The right thing to do is very printer, ink, and paper dependent.
A static, simple CMY->CMYK conversion can do quite well for a lot of
purposes, but it won't satisfy the real high end.
Robert Krawitz <[EMAIL PROTECTED]>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
Gimp-developer mailing list