From: "Robin Rowe" <rower@xxxxxxxxxxxxxxx> Date: Wed, 23 Oct 2002 18:47:54 -0700 Robert, > 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 <rlk@xxxxxxxxxxxx> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lpf@xxxxxxxxxxxx Project lead for Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
