[Printing-architecture] [Gimp-print-devel] [Openicc] Colour
Hal V. Engel
hvengel at astound.net
Mon Nov 16 13:08:51 PST 2009
On Monday 16 November 2009 09:36:26 am Kai-Uwe Behrmann wrote:
> Am 16.11.09, 13:09 +0100 schrieb kate price:
> > Hi all
> > I've been reading all posts with varying levels of comprehension, but
> > always with great interest.
> > To get back to my own concern, design of the UI for the CPD I'm going
> > to boil this down to a quite high level statement which expresses the
> > direction we believe the CPD should take. This is not only in response
> > to the information gleaned here, but also very much in the context of
> > our own convictions about the design of a print dialogue for all users.
> > So:
> > *If printing doesn't exist, colour printing also doesn't exist. Terms
> > and concepts like colour management and ICC profiles have no meaning
> > to a vast majority of users. Most users want their colour printing to
> > just work with no intervention required.
> Agreed, most users do not need to know about techical details.
> As soon as they want colour to just work, ICC colour management is the
> right choice to get this done. So at least the results of colour
> management are understood, and meeting of expectations regarding colour is
> part of how they are satisfied with the print system.
> > *Successful colour printing is as much about media as it is about the
> > ink which goes on it. This means that for successful colour printing
> > from the CPD a holistic picture of the print is required.
> Colour experts will largely agree.
> > *Detailed controls of colour settings, detailed proofing of colour
> > fidelity etc. is far better suited to and achievable within the print
> > preview of a suitable application (GIMP, photoshop etc etc).
> Is it planed to omit a detailed print preview? I have seen this kind of
> windows and modes in office applications, mainly to walk through multi
> page documents before printing. They are very useful there.
I think the CPD design probably needs to be clarified for those who have not
had a chance to review the current design. The CPD has a print preview that:
1. Is always displayed unless the user says "just print" which bypasses the
2. Has a fixed size and is fairly small.
3. The preview is NOT intended for proofing since it's small size makes it of
limited usefulness for this and the apps that are used by users who need/want
soft proofing generally already have this built in or available as a plug-in
While I am not sure that I totally agree with these design choices they are
reasonable and are a good starting point for moving forward.
For more details on the UI design see
> How is the print preview integrated with CPD? Shall it work like a
> button inside CPD, which calls into the main application with some
> parameters to render the preview on application side? Or is it a tab?
The CPD does not use tabs. See the above link for details on why this is the
case. Keep in mind that the CPD is designed for the new PDF based printing
work flow so it expects that the app will pass it a PDF file and this is used to
render the preview. The same PDF is passed to the back end when the users
commits the print job.
> A link to according documentation would be great.
See the above link.
> > *Professionals and power users and enthusiasts need to be able to use
> > profiles and presets they have made or downloaded. Therefore there is
> > a clear need to use colour presets directly from the CPD, even if it
> > is accepted that they cannot be made within the CPD.
> How can we learn details about CPD presets? What makes it difficult to
> dump out a CPD preset?
Users can create CPD presets and these are persistent. A static set of
presets are also configured in the PPD file by the driver vendor so that certain
presets are vendor/device specific and always present. IE. there are a set of
presets that are specified by the vendor in the PPD file that are always present
unless a local admin has modified the printer PPD file.
I don't know anything about extracting and sharing user created presets.
> > Practically this means that:
> > *Color controls are not in the CPD or at the very most, barely there.
> While the idea was provided to hide low level ICC options, I would
> see it as an disadvantage to have the ICC related controls not
> available and would favour to make the outlined CM controls available in
> CPD through a experts only panel,
The CPD is for the most part controlled by the contents of the printer PPD
file. Controls are grouped and those groups are presented to users who can add
or remove these groups from the controls that are displayed. Controls can be
in more than one group but are only displayed once. In the CPD these groups
are called tags. By enabling or disabling these tags the user can make the
CPD as simple or complex as they want within the limits of what is exposed in
the PPD file. In its simplest form the CPD only has controls to select
presets, to select the queue, to enable the selection of tags and to select
the number of copies printed along with the preview.
I believe that it is possible to have tags and controls that are not specified
in the devices PPD file for doing things that are not printer specific. This
could be used to have a Color Management tag for those controls related to
this functionality. For users who choose one of the vendor created presets CM
will likely be set to use the system default profiles and CM processing path.
Advanced users should be able to create presets for printing targets that
completely disable all color processing and other presets for certain types of
prematched printing if the back end can not be configured to correctly handle
profile selection. I think we should be able to make the need for prematching
a very rare occurrence if we can get Oyranos/CUPS and friends to work
correctly. But I think it could take some time to get all of this working the
way we want.
Currently there are no CM controls available on the CPD unless those are in
the devices PPD file (and none have this that I know of).
> which has a reset button for getting
> easily to the defaults.
> But if not, how can applications plug-in a own CM panel into CPD?
> As well looking at Windows and osX print dialogs, there are a lot of
> colour controls. These are not the expert controls you wrote about.
> Nevertheless they are a big selling point for photo printers.
> Delivering vivid, natural, sepia and other effects on button click
> including a canned ICC profile mode is typical integrated into driver
> panels of photo capable printers. Why would print manufacturers wast that
> space if it would be of no need?
> As well I expect most home users have a photo mode in their printing
> device. They print mostly letters but from time to time as well images
> and flyers. So this kind of ICC colour controls matters.
> > *Let the API take the strain: i.e automatic colour control override is
> > desirable and achievable.
> You mean setting and freezing colour related controls as soon as a ICC
> profile is selected(?) This would be the correct mode for the use of ICC
> profiles. Somehow CPD has to know, which settings are colour related for
> the particular driver. This can eigther be transported through Oyranos or
> the profile itself, which again can be translated by Oyranos.
> There will be people who complain about the missed capability to hand
> tweak their colours. This is quite natural. A way to satisfy those
> demand is to support effect profiles, which fits well with the point
> > *Focus on at the practical process of getting presets into our CPD
> > interface to work for enthusiasts and professionals alike.
> > It seems to me that a good focus from here would be to really get the
> > presets working for the most sophisticated users (as well as others).
> > This would be an area where further imput from interested parties
> > would be welcomed because I believe that there is a great opportunity
> > already here within the current design of the CPD. Surely integrating
> > the making, saving and using of these presets into a smooth and
> > comprehensible part of a print workflow would be a great -and
> > importantly- achievable step forward that we can provide?
I agree with this. When I saw how the CPD was designed to work at the
OpenPrinting Summit in April I was impressed by how flexible and user centric
the UI design for the CPD is. IMO it is the most advance printing UI in
existence and it shows a lot of promise for moving things forward. About the
only things missing at this point are how CM should be presented and almost
none of the vendor PPD files are setup to take full advantage of the CPD (PPD
extensions were created to support these advanced CPD features and most PPD
files do not use these yet).
> A big advantage of dumping out a preset is better supportability. With
> dumped files, it is possible to send such a preset to a knowledgeable
> person for remote analysis.
> Cloning presets is for administrators and for sharing among people equally
Admins need a way to create presets that are available for all users of a
given queue/printer. Doing this by modifying the PPD file on the server is
only acceptable as an interim measure. This is very important for the CM
related presets for shared printers in organizations that need to have
professionally configured color managed print queues. For example color
consultants/experts should be able to calibrate and profile a
printer/media/drivers settings combination and then create a preset that will
always set the printer up correctly (IE. select the correct paper tray, set
the right driver settings, use the correct profile, lock down any controls that
affect color...) and that preset should be available to any user who uses that
printer/queue. Then all users have to do to get a hand configured color
managed print is to select that preset.
This would be useful even for local print queues. For example my wife likes
to print photos and complains about how complex it is to get the same quality
of results that I do. Her complaints are justified IMO since it requires
jumping through hoops that are difficult for non-color experts to understand.
If I could configure a preset that did everything to insure that the correct
things would happen I could label that preset something like "Print Photos on
XXX Paper" and all she would have to do is load the correct paper into the
printer and select the custom preset. I am sure that this would make my wife
happy and it would also mean that I would not have to assist her every time
she wanted to print some photos (which I think would also make her happy).
> Regarding ICC profiles, a preset package would need to include the ICC
> > Kate
> > Kate Price
> > man + machine interface works
> kind regards
> Kai-Uwe Behrmann
More information about the Printing-architecture