Digital BW, The Print

> With the current state of the driver, you'd still have to convert to a 
> color file and apply curves. So you're not really any farther ahead. 
> Given the 100% GCR occuring in raw CMYK mode, I'd say curves for that 
> inkset will be difficult. I'm not sure there would be any particular 
> advantage over the Epson driver other than working and building curves 
> in CMYK is more intuitive than RGB, but your file will be 1/3 larger.
> The kind of work John is trying would allow assigning color inks to 
> tonal values from a grayscale file, but it's way beyond me and not 
> available with the standard version of the driver dummies like me would 
> be using.
> Tyler

Well, for me, being waaaaaaaaaaaaaay more of a dummy than you, it is
just really exciting to know that folks like you, John, Paul, whoever
else, have access to tools that will allow you to optimize the
workflow past what the epson driver allows. And what's better is that
the drivers are genuinely cross-platform, so maybe in time this could
be the system we're all using. 

Here's what I picture (and, bear in mind of course, that I'm good at
coming up with wishlists but darn near incompetent when it comes to
implementing this stuff.) -

An "automate" plugin/script for Photoshop which would:

Take a "final" greyscale file as source, give choices for various
inksets and tones, create appropriate separation files and output a
"ready to print" file that can go straight to the gimp drivers. 

Seems to me that this would probably work a lot like the PS "duotone"
function, which applies curves and creates separations. (Actually, I'm
wondering why we don't use that function for applying curves?) I would
expect that there would be three hard parts - 1. coming up with the
curves and seps for all different inksets 2. actual driver development
stuff to make sure the CMYK issues you were mentioning (equal parts
CMY printing with K instead) get solved 3. Figuring out how to make
sure the right channels print with the right tones (perhaps that's the
same as part 2)

I am a terrible, terrible programmer - but I have a lot of experience
in software management and I'm great at writing functional specs and
that sort of thing. If it would be helpful for the people actually
working on this stuff, I'd be very happy to work on design docs or
anything of that nature. (And of course if it won't be helpful I'll be
happy to never mention this again :) )