[Openicc] Introduction / Gutenprint

[Kai-Uwe Behrmann]

Am 11.04.05, 01:06 +0200 schrieb Craig Bradney:

> On Monday 11 April 2005 00:56, Gerhard Fuernkranz wrote:
> > Craig Bradney schrieb:
> > >Dont forget print previews must also handle CMS and plate separation (as
> > >Scribus does now, via GS).
> >
> > IMO this leads to the question:
> > Is a soft proof or print preview a task for the printing subsystem or
> > for the application?
> 
> Depends at what level you end up talking to drivers and what is used to 
> generate previews. Eg, we cant generate previews that show transparency 
> properly (until we write a flattener) as PS doesnt handle it at all. 
> 
> You should not have to rely on a printer being installed, or the correct one. 
> Remember, you will be exporting to PDF in the DTP case more and more as the 
> commercial RIPS come up to standard, and therefore never ever actually use 
> your own printing system, and a lot of people have not even one clue about 
> setting up their own system with a PPD for a dumb printer, let alone a RIP 
> based printing system.

.. generally agreed to the path of device independence

some annotations dedicated to proofs and previews:

The softproof feature in Scribus is very valuable. It incorporates only 
the source and target profiles. While the target profile can be a standard 
printing space like SWOP or an individual printer profile. The printing 
system is not needed at any point on the production system.
Scribus can, with relyable profiles, produce repeatable output(to some 
degree) without the need of physical printing devices. For many users with 
calibrated monitors this may be allready sufficient. This is maybe what 
Craig is refering to.

The proof on a printer provides more relyability, some people want not to 
miss. Needed for this hard proof are source and target profiles and a 
simulation profile.
This means a document comes with a full colour description and a desired 
target profile. The CM/RIP would find thats not me you are asking for, and 
try to simulate the desired output on the actual device with its own 
profile. Open here is: the users needs feedback / warning about the size 
and values the proof differs from the softproof profile. This can be 
computed by comparing the target and simulation profiles and the actual 
image data. For instance the missbeheave of spot colours on a proofing 
system should be mentioned to the user. The printing subsystem will not 
render a preview.

The other way around specialized applications will request the profile of 
the actual used proofer and care about the above scenario - gamut 
differences notification ...  Additionally the lack of spot colours on 
the proofer can be more easily marked and rendered on screen. The proof is 
then rendered to a local proofer (usual case) in the final n-colours and 
bandwidth is no odds.

Maybe the combination will look otherwise. What does you think?

regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name