Re: Re. inkjets: An open letter... Gutenprint and CUPS
Re: Re. inkjets: An open letter... Gutenprint and CUPS
- Subject: Re: Re. inkjets: An open letter... Gutenprint and CUPS
- From: Jan-Peter Homann <email@hidden>
- Date: Wed, 21 May 2008 11:30:25 +0200
hello all,
Some time communication over mailinglists is not easy...
From my point of view one of the core problem for colormanagement in
the printing chain is the intransparency how colormanagement at the
applications, the OS / Graphics API / Spooler and the Printer driver
interacts.
As a result, printing the same image with an embedded profile from
different applications on the same printer with the same driver settings
and the same printer profile can lead to very different results.
Such problems are well known e.g. either between Photoshop and Indesign
on Mac OS X or e.g. between Adobe an Apple applications.
The core problem is, that the ICC specs define a profile format and do
not deliver a reference design, how applications, OS, Graphics API /
Spooler and printer driver interact.
I want Adobe and X-Rite pushing the ICC (and Apple) to give the power
user, the dealer and the colormanagement consultant a tool which shows
as textline on print what happens concerning colormanagment from the
application over OS... to the printer driver. I also hope that the Open
Source team at CUPS and Gutenprint find such idea useful to implement it
in later versions.
Lets look at an virtual example:
The printing application would store the colormanagement settings of
application print setup as meta-data into the printing data:
Application: AdobeRGB relcol with BPC to Myprinter.icc
If the OS does any colormanagement, it stores it also as meta data in to
the print chain:
tagging with GenericRGB
The printer driver prints the meta-data as textline and adds further
informations about driver settings:
GenericRGB perceptual Vendorprinter.icc, photopaper, 720DpI, high quality
The textline / control slug would show what happens:
- Application: AdobeRGB relcol with BPC to Myprinter.icc
- OS: tagging with GenericRGB
- printerdriver: GenericRGB perceptual Vendorprinter.icc, photopaper,
720DpI, high quality
The user intended orginally to do the colormanagement to the printer on
application level and thought, that both the OS and the printer driver
don´t do any further colormanagement.
But instead it happens that the OS tagged the correct printing data
wrongly with generic RGB and also the printerdriver did a second color
transformation.
Currently the user has to guess what happens. With the proposed concept,
he could easily identify, where the problem is.
In further stage, we need a certification system, that certified
applications, OS and printerdrivers interact in a way, that described
things like unwanted automatic tagging of prindata or double
transformations don´t happen.
Such certification system would allow e.g. vendors to test if updates of
their applications, OS-functions and printer drivers behave correct or
if they need to do any thing. It also helps power users, support-team
from vendors and consultants to identify problems, find faster work
around on improve faster the products.
Hopefully this example was less philosophical... ;-)
Regards
Jan-Peter
edmund ronald wrote:
Jan Peter - you need to be a bit clearer, maybe less philosophy and
more explanation of the technical terms - my American is not that good
(I am from Great Britain and not from the US), and so I have trouble
in understanding what you mean.
Edmund
On Tue, May 20, 2008 at 4:21 PM, Jan-Peter Homann
<email@hidden> wrote:
Hello Robert, hello list
As a user, i want to have the option to have control slug right on the print
out, which shows as text line what colormanagement actions has happened to
print data from the printing application, the OS / printer spooler and the
printer driver.
being not a developer I would desscribe it as following:
- The application generates meta-data about the colormanagement-settings
during printing and embedds into the spool-data
- if the OS or the spooler do any colormanagement tasks, they will also be
embedded into the meta-data
- the printer driver adds at least the basic driver settings (media,
resolution, dithering linearization-file) and prints all together with the
final motive on the print out.
Especially in Environments which are allowing colormanagement for the print
chain on application level, OS-level and output-level (printer driver or
RIP) such control slug is - in my eyes - a key component to for transparent
and predictable colormanagement in the printing chain.
Concerning e.g. Mac OSX, Adobe Creative Suite and several printer drivers,
it is today often impossible to understand and to predict what happens in
the printing chain concerning color management.
Giants like Apple, Adobe Canon, Epson and HP which really have the
ressources to analyze and fix such problems are not able to deliver
solutions.
If we would have a working solution with CUPS and Gutenprint, this would be
a big step forward.
Regards
Jan-Peter
--
*********** Neue Adresse / new adress ************
homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Christinenstr. 21 ------ http://www.colormanagement.de
10119 Berlin -------- mailto:email@hidden
*********** Neue Adresse / new adress ************
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden