[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-openicc
Subject:    Re: [Openicc] Is CUPS the right place... (CUPS and ColorSync)
From:       Kai-Uwe Behrmann <ku.b () gmx ! de>
Date:       2011-02-08 22:15:39
Message-ID: alpine.LNX.2.00.1102082307110.4958 () roma ! rasena
[Download RAW message or body]

Am 08.02.11, 11:30 -0700 schrieb Chris Murphy:
> On Feb 8, 2011, at 12:19 AM, Kai-Uwe Behrmann wrote:
> > Am 07.02.11, 16:00 -0700 schrieb Chris Murphy:
> > > On Feb 7, 2011, at 3:31 PM, Jan-Peter Homann wrote:
> > > > But we still should consider, that the described workflow has some critical \
> > > > points. If all parts of the PDF should be converted to the profile of the \
> > > > printer setting by embedding this profile as Output Intent into the PDF file, \
> > > > it is mandatory, that every PDF-object is a ICCbasedRGB or ICCbasedCMYK \
> > > > object.
> > > 
> > > It's not required they be ICCBased. Leonard's flow chart describes the \
> > > alternatives if the objects are not ICCBased. The user can specify working \
> > > spaces (defaults) in e.g. Gnome Color Manager, and then colord makes this \
> > > available to GhostScript, which would then use an assumed profile workflow to \
> > > convert the objects from source to OutputIntent.
> > 
> > But again, that is very fuzzy and unrelyable - developers call it a hack.
> 
> Which part is fuzzy and unreliable? Also it's important to separate PDF Export from \
> PDF print spool file. When I think of a PDF print spool file, I think of a PDF with \
> an OutputIntent (unless it's a profile target). I'm not thinking of OutputIntents \
> for PDF Export unless the user has explicitly chosen a PDF/X standard.

Placing the profile selection, editing space and print profile, into CUPS 
server is very fragile. The CUPS server part has not much of a relation to 
users. In contrary the CPD is running in the user environment.

> > > You're much better off properly building PDF/X-4 documents, honoring the \
> > > original color space of the objects, until the actual output condition is \
> > > determined. Objects need to be properly tagged, not set in device space unless \
> > > the application producing those objects really understands what it's doing, and \
> > > needs to preserve device channel integrity for some reason.
> > 
> > Agreed. For most applications the editing space will be simply sRGB. So its sane \
> > to set sRGB as the ICCbasedRGB space, as was pointed by Chris. 
> > Applications, which do not care about colour management, will naturally adhere to \
> > sRGB as their paradigm. This is already a single flat colour space for blending \
> > and I guess what Jan-Peter primarily wanted.
> 
> I think what we are proposing, for "dumb" applications that think they 
> are writing out /DeviceRGB is that either the PDF Export file, or the 
> PDF print spool file, tag the objects in the PDF as sRGB. The PDF print 
> spool file would also have an OutputIntent that matches the ICC profile 
> chosen by the user (or automatically selected based on driver settings, 
> if this gets implemented), and GhostScript+lcms convert.

PDF printing is young on Linux. Want we really to start with tricks right 
from the beginning. We can teach PDF creators to to simply tag objects 
with sRGB and done. Using DeviceRGB when sRGB is meant is not clear.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

_______________________________________________
openicc mailing list
openicc@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openicc


[prev in list] [next in list] [prev in thread] [next in thread]