[Openicc] GoSoC 2011: CPD and target printing

[edmund ronald]

On Thu, May 5, 2011 at 4:07 AM, Chris Murphy <lists at colorremedies.com>wrote:

>
>
> On May 4, 2011, at 7:28 PM, edmund ronald wrote:
>
> Chris,
>
>  Maybe I find devicespace to be really useful to have around as a working
> space.
>
>
> Device spaces make pretty hideous working spaces (i.e. image editing
> spaces). They aren't gray balanced, they can have cross overs, they have
> non-linear behaviors that don't match up among the channels, and if the
> device space is literally ink controlling, you can rapidly run into
> individual channel and total ink limit problems. I think this is very
> special use case. It's a very sharp unforgiving razor black for 99.2% of the
> user market.
>
> If you're really going to build software for 0.8% of the market, where I'm
> not even included, I personally don't find that very interesting. It's way
> out there. And that's fine. I don't think such software should be restricted
> from being built or from working the way the developers and users want it to
> work. But I don't think there should be a big razor blade launching device
> in every print dialog for all applications pointed right at the user even if
> it's hidden by default behind an advanced panel. I think it's something that
> only certain apps should reveal.
>
>
>
> -  retouch in the printer space is a habit I fell into for my exhibition
> prints.
>
>
> I think this is fallout from working with crappy drivers, and possibly also
> not such great profiles built for use with crappy drivers. And early on in
> this whole adventure we did have some pretty crummy "raw" color modes from
> manufacturer drivers. Still have this in some cases.
>
>
> -  When printing with Gutenprint I find I often prepare files on a Mac, use
> Photoshop to do color conversions, and then move the file onto Linux *just*
> for the final print which is thus made as if the print were a target.
>
>
> OK but I think we're talking about a workflow of 1-5 people on the whole
> planet. I don't think we can build an opt-out system that's going to allow
> you to opt-out of every single application. This is why this opt-out vs
> opt-in question is rather important to establish. But I don't see why the
> opt-out would be needed in a web browser or some new photo portfolio tool.
> These things should just work correctly for display and print. I don't see
> how you'd even use them for printing targets. It's like using a pasta
> rolling machine as a refrigerator. I'm only seeing incongruence.
>
>
>
>
>
>
> - I I always have countless small problems with targets, want to move them
> around on the paper or legend them so I remember what they are. These mods
> are best done in the GUI with the same type of app that is usually employed
> for layout and printing.
>
>  Look, you may have a different workflow, and you can have a special target
> printing app for all I care; I would like to be able to print my targets
> from the GIMP.
>
>
> I think the Gimp will need to implement the opt-out themselves. I remain
> unconvinced the the opt-out mechanism should be in the CPD for every single
> application. I see no reason why the Gimp would not subscribe to this
> opt-out for printing targets or prematched content. That would be the whole
> point of the opt-out system.
>
>
> Chris Murphy
>


Chris,

 I simply cannot envision printing targets from a command-line app. Sorry.
At this point, if this is the decision taken here, I will resign from this
endeavor.

Edmund
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110505/c93d571d/attachment.htm>