[Openicc] Introduction / Gutenprint

[Craig Bradney]

On Monday 11 April 2005 00:50, Gerhard Fuernkranz wrote:
> Bob Friesenhahn schrieb:
> > Beyond telling the printer driver which profile describes the existing
> > image data, and which profile describes the printer, what additional
> > functions are required of an open color management system in order to
> > support printing?
>
> IMO the general case (e.g. desktop publishing) is that a page contains
> not only a single image, but several objects (images, vector graphics,
> text, etc.), where each of the objects may be represented in a different
> (source) color space, and may need to be rendered with a different
> rendering intent.
>
> Basically I imagine the following printing flow:
>
>     Application -> page description (PS, PDF, PCL, or whatsoever) ->
>       -> Spooler(optional) -> RIP -> printer
>
> If the CM is done in the application, then the application will convert
> all object colors to the printer's native device color space and the
> page description will only refer to colors in the printer's color space.
> The resulting page descript is bound to a particular printer and cannot
> be used on a different printer.
>
> If no color conversions are done in the application, and the CM is
> delegated to the printing subsystem, then the page description created
> by the application needs to contain all objects in their original color
> spaces, together with descriptions (profile) of all these color spaces,
> and rendering intents for the objects, in order that the RIP can
> eventually convert all objects to the printer color space. In this case
> the CM is eventually done in the RIP. Since the color conversion is
> delayed, the same page description may be even usable with different
> printers.
>
> The use of different rendering intents for different objects may even
> require to use not only a single printer profile, but several ones (for
> instance, if a different black generation is desired for different
> objects, etc.).
>
> In the first case (CM in the application), the "page description" could
> also be a simple page image in the printer's native device color space.
> In the second case this is no longer possible (severel objects in
> different color space need to be represented) and a more sophisticated
> page description is required.
>
> That's a brief summary of my understanding of printing, but maybe others
> have a completely different understanding.
>
> Regard,
> Gerhard

Dont forget print previews must also handle CMS and plate separation (as 
Scribus does now, via GS).

Craig