[Openicc] Printing Plans ... PPD color options

[Jan-Peter Homann]

Hello James, hello list,
The complaints are not about the options how to handle gray / black 
objects which are encoded in RGB.
The complaints are about the possibilities, that the user is allowed to 
assign ICC-profiles for a spool file which has only objects in deviceRGB.

INternational standards like e.g. IEC 61699, some W3C standards and 
vendor standards like Microsoft redommendations define, that untagged 
RGB-data should always (!!!) be handled as "sRGB".

If user get the possibility to assign other profiles than sRGB to  
objects of the spool file, it will lead in 99% of the cases to wrong 
colors in printing.

The correct way to deal with other profiles than sRGB, is a workflow, 
where such profiles are transferred from the document directly to to the 
sppol file whithout any user intervention.

The current problem under LINUX is, that PostScript as a print spool 
file format can not handle ICC profiles, and the QT libraries for 
creating PDF-spool files are not able to handle ICCbased PDF objects.

Concerning rendering intents, the options proof (relativ colorimetric) 
and match (absolut colorimetric) do not make sense in office based 
workflows. Both options can lead to loos of details in either dark or 
dark and light colors,

Stripping off the "make my colors worse" option lead to following PPD

     Image RGB Intent:    Business *Picture
     Text RGB Intent:     *Business Picture
     Graphics RGB Intent: *Business Picture



Kind regards
Jan-Peter

Am 04.03.11 21:05, schrieb James Cloos:
>>>>>> "CM" == Chris Murphy<lists at colorremedies.com>  writes:
> CM>  I'm just shaking my head...I don't have a coherent response to a PPD
> CM>  that looks like such utter bollocks.
>
> All of the postscript colour lasers I looked into work that way.
>
> And the docs show that the (usually pcl-generating) doze drivers offer
> the same options.
>
> CM>  If this is a common PPD, we have our work cut out for us on another
> CM>  front which is what options should and and should not appear in PPDs.
>
> Why shouldn’t they?  The out of box defaults are sane for most users.
> The ability to choose between expensive CMY or inexpensive K for RGB
> gray is clearly a feature demanded by users (using CMY for gray costs
> more than five times as much USD than using K, but gives noticeably
> better results in photographs and the like).
>
> Remember that papers (usually, I’m sure, due to author naïveté)
> frequently use images where a vecotr graphic should have been used.
> And when so they are essentially always in DeviceRGB.  So you can’t
> just say «use CMY for images and K for graphics».  The users need
> to be able to set a default, but still override that default on a
> per job basis.
>
> The manuacturers of RIP printers have now had, what, twenty years or
> so to figure out what controls the users want and how to present them.
>
> And for cups-based print flows, the only way *to* do those per-job
> overrides is via PPD options.
>
> (The PPDs use setpagedevice postscript snippets; the printers generally
> also support using PJL to set those options.)
>
> I just do not understand the complaint....
>
> -JimC


-- 
----------  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