[Openicc] Thoughts IEEE PWG

[Jan-Peter Homann]

Hello list, James and Chris
Thanks for linking to the IEEE PWG.
I took a first overlook about the published papers and standard 
concerning color management, documents file formats and media definitions.

My first impression, is that the current IEEE PWG focus is on sRGB based 
only workflows.
discussed documents formats are e.g. XHTML Print, CUPSRaster and PDF 
containing only raster files.

I have seriuosly doubts, that printing infrastructure conforming to IEEE 
PWG will be able  to proper colormanage blog entries  containing images 
with different embedded ICC profiles, or to reprint a PDF/X file, which 
was created first time for offset printing.

The best way IEEE PWG could do to avoid color management problems, would 
be a clear statement, that the client should render all color objects to 
sRGB, before sending it to an IEEE PWG conforming printing service.

I think OpenICC is community, where it is mandatory, that OpenICC 
conforming workflows should support both a sRGB appoach with simple UI 
and complex ICCbased workflow for color enthusiast and color 
professionals with an UI necessary for dealing with complex ICC workflows.

So i don´t see where IEEE PWG could make a positive impact for OpenICC 
topics.

best regards
Jan-Peter



Am 09.05.11 06:15, schrieb Chris Murphy:
>
>
> On May 8, 2011, at 4:42 PM, James Cloos wrote:
>
>> Is anyone here active in the IEEE’s PWG?
>>
>> Among their other working groups, they are currently working on a
>> specification for “cloud printing”¹.  The two interesting outcomes
>> should be a strong takeup by the printer manufacturers of IPP over
>> USB and the PWGRaster² format.  That combination should have a
>> /significant/ positive impact on our needs.
>>
>> It is very unlikely that there will be any significant use of the CPD
>> except for legacy apps (which currently use lpr(1) or lp(1)) and as an
>> example dialog the authors of frameworks like GTK and qt might use when
>> designing their own print dialogs.  Ie, a separate application will not
>> fly for most apps authors.
>>
>> As such, we should not rely on or wait for the CPD.  Most of the use of
>> the initialism CPD instead should specify “print dialog”.
>>
>> (Which is not to suggest that the CPD should be abandoned or anything;
>> it should be completed.  But we must be realistic about its future.)
>>
>> 1] Please excuse the use of the marketing gobbledygook “cloud”.  Bleh.
>>
>> 2] A proper subset of CUPSRaster.
> I agree with this as well as Richard's concerns about over dependency on the CPD. We need to be thinking of how to enable ICC in all methods, including CPD, but not just CPD. I have big concerns with a major backtrack with color management when it comes to cloud and mobile printing right now. It's fine that for 95% of the market it will (likely) be sRGB based, but I still think we need to wedge ourselves in assertively to get better results than this for more discerning amateurs and professionals.
>
> Chris Murphy
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>


-- 
----------  Please note the new adress --------------

homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:homann at colormanagement.de