1 2\documentclass[12pt,notitlepage]{article} 3%\usepackage{osa2} 4%\usepackage{overcite} %% PRODUCES SUPERSCRIPT REFERENCE CITATIONS 5%\usepackage[comma,sort&compress,nonamebreak]{natbib} 6%\bibpunct{[}{]}{,}{n}{}{,} 7%\bibpunct{\textsuperscript{}}{\textsuperscript{}}{,}{s}{,}{,} 8%\citestyle{nature} 9\usepackage{epsfig,url} 10\urlstyle{same} 11 12\oddsidemargin 0in 13\evensidemargin 0in 14\setlength{\paperheight}{11in}% 15\setlength{\paperwidth}{8.5in}% 16\setlength{\textwidth}{\paperwidth}% 17% subtract for the 1" top/bottom margins 18\addtolength{\textwidth}{-2.0in}% 19\setlength{\textheight}{\paperheight}% 20\addtolength{\textheight}{-3.0in}% 21 22\usepackage{setspace} 23\usepackage{amsmath} 24\usepackage{color} 25\usepackage{hyperref} 26\usepackage[ansinew]{inputenc} 27\pagestyle{myheadings} \markboth{ Artifex Software Inc. www.artifex.com }{Artifex Software Inc. www.artifex.com} 28 29\begin{document} 30 31\begin{titlepage} 32 33\begin{center}{\huge \bf Ghostscript Color Management\\} \vspace{0.5in} {\Large Michael J. 34Vrhel, Ph.D.\\} {\Large Artifex Software\\} {\Large 7 Mt. Lassen Drive, A-134\\} {\Large San Rafael, CA 94903, USA\\} 35{\Large www.artifex.com\\} 36\end{center} 37\vspace*{0.5in} 38\begin{abstract} 39This document provides information on a redesign of color management within Ghostscript. Due to its long history of development, Ghostscript's color management has been heavily based upon PostScript Color Management. The new design is focused upon an ICC workflow, which is common today in the printing community. The new design provides significant flexibility for customization by 3rd parties including the ability to interface to other color management modules. This document provides an overview of the architecture as well as usage and developer information. 40\end{abstract} 41\begin{center} 42\vspace*{0.25in} 43Revision 1.0 44\vspace*{0.25in} 45\begin{figure}[h] 46 \begin{center} 47\includegraphics*[width=1.5in]{figures/Ghost.eps} 48 \end{center} 49\end{figure} 50 51\end{center} 52 53\end{titlepage} 54 55\renewcommand{\baselinestretch}{1.67}\normalsize 56%\maketitle 57 58\clearpage 59 60\singlespace 61 62\section{Introduction} 63 64This document covers the overall architecture of a new approach to ICC color management\cite{ICC} within Ghostscript. The document is organized to first provide a higher level overview of the new ICC flow as well as how to make use of the new architecture. This is followed by details of the various functions and structures, which include the information necessary to interface other color management modules to Ghostscript. 65 66The overall motivation for this work is to modernize the color flow of Ghostscript and in particular make it much easier for our customers to use their own color management systems (CMS). Many RIP manufacturers have designed their own color management systems to provide a marketing advantage over their competitors 67 68Today, almost all print color management is performed using ICC profiles as opposed to PostScript\cite{PS} Color Management (PCM), which predates the ICC format. Ghostscript was designed prior to the ICC format and likely even before there was much thought about digital color management. At that point in time, color management was very much an art with someone adjusting controls to achieve the proper output color. The current methods used for performing device independent color in Ghostscript are computationally costly due to the use of multiple transforms. This new color flow addresses that issue through the use of linked transforms that can be readily applied to buffers of data. 69 70Many customers wish to apply different color transformations depending upon if the object being drawn is an image, a graphic or text. The common example is that it is desirable to use pure black as opposed to composite black when drawing black text. In addition, with an image, you likely will want to use a more perceptual based gamut mapping method but with a graphic you likely want to use a more saturated method. 71 72Given these many concerns, the requirements of the architecture are as follows: 73\begin{itemize} 74\item It must be easy to introduce a new CMS into the build of Ghostscript. 75\item There must be objects/methods to manage the ICC profiles and the linked transforms. 76\item It must be possible to define all color spaces in terms of ICC profiles. 77\item It must be possible to have the CMS operate on buffers of data. 78\item Devices can communicate ICC profiles and have their ICC profile set. 79\item It must work with PostScript color management definitions. 80\item It must be possible to cache the linked transformations that define the mapping from one color space to another so that we avoid having to recompute links when we have frequently changing color spaces. In addition, it will be necessary to do lazy linking of these mappings (e.g. only create a mapping when requested to transform data). 81\item It must have the ability to incorporate the object type (e.g. image, graphic, text) and rendering intent into the computation of the linked transform. 82\item It must be designed to operate efficiently in a multithreaded environment. 83\end{itemize} 84 85Figure \ref{fig:ICC_ARCH} provides a graphical overview of the various components that make up the architecture. The primary components are the ICC Manager, which maintains the various default profiles, the Link Cache which stores recently used linked transforms, the profiles contained in the root folder iccprofiles, which are used as default color spaces for the output device and for undefined source colors in the document, and finally the color management system (CMS), which is the external engine that provides and performs the linked transformations (e.g. littleCMS). 86 87In the typical flow, when a thread is ready to transform a buffer of data, it will request a linked transform from the Link Cache. When requesting a link, it is necessary to provide information to the CMS, which consists of a source color space, a destination color space, an object state (e.g. text, graphic, or image) and a rendering type (e.g. perceptual, saturation, colorimetric). The linked transform provides a mapping directly from the source color space to the destination color space. If a linked transform for these settings does not already exist in the Link Cache, a linked transform from the CMS will be obtained (assuming there is sufficient memory -- if there is not sufficient memory then the requesting thread will need to wait). Depending upon the CMS, it is possible that the CMS may create a lazy linked object (i.e. create the real thing when it is asked to transform data). At some point, a linked transform will be returned to the requesting thread. The thread can then use this mapping to transform buffers of data through calls directly to the CMS. Once the thread has completed its use of the link transform, it will notify the Link Cache. The Link Cache will then be able to release the link when it needs additional cache space due to other link requests. 88 89\begin{figure} 90 \begin{center} 91 % \leavevmode \epsfysize=3.0in 92\includegraphics*[width=6.0in]{figures/Overview.eps} 93 \end{center} 94 \caption{Graphical Overview of ICC Architecture} 95 \label{fig:ICC_ARCH} 96\end{figure} 97 98\section{PDL Color Definitions and ICC Profiles} 99 100To help reduce confusion, it is worthwhile to clarify terminology. In particular the use of the terms process color and device color need to be defined in the context of ICC profiles. Both PDF\cite{PDF} and PostScript (PS) have a distinction between process colors and device colors. Figures \ref{fig:PDF_SPEC}-\ref{fig:XPS_RENDER} provide an overview of how color is defined in various PDLs. As seen in Figures \ref{fig:PDF_RENDER} and \ref{fig:PS_RENDER}, there is a conversion (e.g. via UCR/BG) from device colors to process colors for PDF and PS. In an ICC work flow, the colors are transformed directly from an input color space (often called the source space) to an output color space (often called the destination space). The output color space defined by the device's ICC profile is a mapping to what PDF and PS define as the process color space of the device. In other words, the ``device color space'' as defined by the device's ICC profile IS the process color space of PDF and PS. The ICC profile of the device is a mapping from a CIE color space to the process color space AND from the process color space to a CIE color space. 101 102To understand this better, it may help to understand the method by which an ICC profile is created. To create an ICC profile for a device, a chart is printed using its process colors (e.g. CMYK). This chart is measured using a colorimeter or a spectrophotometer. This provides the forward mapping from process colors to CIELAB values. The inverse mapping (from CIELAB to process colors) is obtained by inverting this table usually through a brute force search and extrapolation method. These mappings are both packed into an ICC format, thereby defining mappings between the device ``process colors'' and the CIE color space. 103 104The remaining steps shown in Figures \ref{fig:PDF_RENDER} and \ref{fig:PS_RENDER} consist of transfer functions and halftone functions. It is possible to pack the transfer functions into the ICC profile or have them externally defined as part of the PS or PDF file. It is up to the user to handle this in their desired manner (i.e. they need to design their device ICC profile appropriately). Halftoning of course occurs after color conversion as shown in Figure \ref{fig:PDF_RENDER} and \ref{fig:PS_RENDER}. 105 106\section{Usage} 107 108The code is currently available for checkout with SVN on a branch named icc\_work of the main trunk of Ghostscript. The specific URL is\\ 109 110\textcolor{blue}{\href{http://svn.ghostscript.com/ghostscript/branches/icc_work}{http://svn.ghostscript.com/ghostscript/branches/icc\_work}} 111\\ 112 113\noindent The branch is built in the same process by which the trunk of Ghostscript is built. See the documentation at \textcolor{blue}{www.ghostscript.com} for details. 114 115The ICC branch introduces several new command line options that can be invoked for complete color management control. To define source colors that are not already colorimetrically defined in the source document, the following command line options can be invoked.\\ 116 117\textcolor{red}{-sDefaultGrayProfile=my\_gray\_profile.icc}\\ 118 119\textcolor{red}{-sDefaultRGBProfile=my\_rgb\_profile.icc}\\ 120 121\textcolor{red}{-sDefaultCMYKProfile=my\_cmyk\_profile.icc}\\ 122 123In this case, for example, any source gray colors will be interpreted as being defined by the ICC profile my\_gray\_profile.icc. If these profiles are not set, default ICC profiles will be used to define undefined colors. These default profiles are contained in the root folder directory iccprofiles and are named default\_gray.icc, default\_rgb.icc and default\_cmyk.icc. The profile default\_gray.icc is defined to provide output along the neutral axis with an sRGB linearization. The profile default\_rgb.icc is the V2 sRGB ICC profile and the profile default\_cmyk.icc is a SWOP CMYK ICC profile. In addition to being able to define undefined colors, it is possible to define the ICC profile for the output device using\\ 124 125\textcolor{red}{-sOutputICCProfile=my\_device\_profile.icc}\\ 126 127A directory can be defined which will be searched to find the above defined ICC profiles. This makes it easier for users who have their profiles contained in a single directory and do not wish to append the full path name in the above command line options. The directory is set using\\ 128 129\textcolor{red}{-sICCProfilesDir=c:/my\_icc\_profiles/}\\ 130 131Warnings will be emitted when running a debug version if problems occur with respect to finding the ICC profiles and it is possible that the program may terminate. There are additional optional settings that are currently under development. These include\\ 132 133\textcolor{red}{-sProofProfile=my\_proof\_profile.icc}\\ 134 135\textcolor{red}{-sNamedProfile=my\_namedcolor\_profile.icc}\\ 136 137\textcolor{red}{-sDeviceLinkProfile=my\_link\_profile.icc}\\ 138 139Setting a proofing profile will make the color management system link multiple profiles together to emulate the device defined by the proofing profile. If a named color profile is set, then when named colors are encountered in the document they will be mapped to the proper device values. Note that the code does not require that an ICC profile be used for the named color profile. This is all customizable in the interface code to the CMS. See the details regarding gscms\_transform\_named\_color later in the document 140 141Finally, it will be possible to include a device link profile for other color work flows. For example, this may be useful for devices that output raster content in a standard color space such as SWOP or Fogra CMYK, but they wish to redirect this output to other CMYK devices. While it is possible to handle such a flow in other manners (e.g. using a proofing profile) this is a work flow that is not uncommon. Finally, note that command line options for XPS\cite{XPS} and PCL\cite{PCL} are currently under design. 142 143\newpage 144 145\section{Overview of objects and methods} 146 147At this point, let us go into further detail of the architecture. 148 149\subsection{ICC Manager} 150 151The ICC Manager is a reference counted member variable of Ghostscript's imager state. Its functions are to: 152 153\begin{itemize} 154\item Store the required profile information to use for gray, RGB, and CMYK source colors that are NOT colorimetrically defined in the source document. These entries must always be set in the manager and are set to default values unless defined by the command line interface. 155\item Store the required profile information for the output device. 156\item Store the optional profile information related to named colors (if set), the proofing profile (if set) a final output link profile (if set). 157\item Store the directory be used to search for ICC profiles specified for the above objects. 158\end{itemize} 159 160The manager is created when the imaging state object is created for the graphics library. It is reference counted and allocated in garbage collected (GC) memory that is not stable with graphic state restores. The default gray, RGB and CMYK ICC color spaces as well as the device ICC color space are defined immediately during the initialization of the graphics library. If no ICC profiles are specified externally, then the ICC profiles that are contained in the root folder iccprofiles will be used. The ICC Manager is defined by the structure given below.\\ 161 162\noindent typedef struct gsicc\_manager\_s \{ 163 164\begin{tabular}{lll} 165 & cmm\_profile\_t *device\_named; & \textcolor{green}{/* The named color profile for the device */} \\ 166 & cmm\_profile\_t *default\_gray; & \textcolor{green}{/* Default gray profile for device gray */} \\ 167 & cmm\_profile\_t *default\_rgb; & \textcolor{green}{/* Default RGB profile for device RGB */} \\ 168 & cmm\_profile\_t *default\_cmyk; & \textcolor{green}{/* Default CMYK profile for device CMKY */} \\ 169 & cmm\_profile\_t *proof\_profile; & \textcolor{green}{/* Profiling profile */} \\ 170 & cmm\_profile\_t *output\_link; & \textcolor{green}{/* Output device Link profile */} \\ 171 & cmm\_profile\_t *device\_profile; & \textcolor{green}{/* The actual profile for the device */} \\ 172 & cmm\_profile\_t *lab\_profile; & \textcolor{green}{/* Colorspace type ICC profile from LAB to LAB */} \\ 173 & char *profiledir; & \textcolor{green}{/* Directory used in searching for ICC profiles */} \\ 174 & uint namelen; & \\ 175 & gs\_memory\_t *memory; & \\ 176 & rc\_header rc; & 177\end{tabular} 178\noindent \} gsicc\_manager\_t;\\ 179 180\noindent Operators that relate to the ICC Manager are contained in the file gsiccmanage.c/h and include the following:\\ 181 182\singlespace 183\noindent int {\bf gsicc\_init\_device\_profile}(gs\_state * pgs, gx\_device * dev);\\ 184 185\begin{minipage}[h]{6.0in} 186 187This initializes the device\_profile member variable based upon the properties of the device. The device may have a profile defined in its 188dev$\rightarrow$color\_info.icc\_profile member variable. If it does not, then a default profile will be assigned to the device. 189\end{minipage}\\ 190\\ 191 192\noindent int {\bf gsicc\_set\_profile}(const gs\_imager\_state * pis, const char *pname, int namelen, \\gsicc\_profile\_t defaulttype);\\ 193\\ 194 195\begin{minipage}[h]{6.0in} 196This is used to set all the other profile related member variables in the ICC Manager. The member variable to set is specified by defaulttype. 197\end{minipage}\\ 198\\ 199 200\noindent void {\bf gsicc\_set\_icc\_directory}(const gs\_imager\_state *pis, const char* pname, int namelen);\\ 201 202\begin{minipage}[h]{6.0in} 203This is used to set the directory for finding the ICC profiles specified by \\ gsicc\_set\_profile. 204\end{minipage}\\ 205\\ 206 207\noindent gsicc\_manager\_t* {\bf gsicc\_manager\_new}(gs\_memory\_t *memory);\\ 208 209\begin{minipage}[h]{6.0in} 210Creator for the ICC Manager. 211\end{minipage}\\ 212\\ 213 214\noindent cmm\_profile\_t* {\bf gsicc\_profile\_new}(stream *s, gs\_memory\_t *memory, const char* pname, int namelen);\\ 215 216\begin{minipage}[h]{6.0in} 217Returns an ICC object given a stream pointer to the ICC content. The variables pname and namelen provide the filename and name length of the stream if it was created from a file. If it came from the source stream, pname may be NULL and namelen would be zero. 218\end{minipage}\\ 219\\ 220 221\newpage 222 223\noindent int {\bf gsicc\_set\_gscs\_profile}(gs\_color\_space *pcs, cmm\_profile\_t *icc\_profile, \\gs\_memory\_t * mem);\\ 224 225\begin{minipage}[h]{6.0in} 226Sets the member variable cmm\_icc\_profile\_data of the gs\_color\_space object (pointed to by pcs) to icc\_profile. 227\end{minipage}\\ 228\\ 229 230\noindent cmm\_profile\_t* {\bf gsicc\_get\_gscs\_profile}(gs\_color\_space *gs\_colorspace, gsicc\_manager\_t *icc\_manager);\\ 231 232\begin{minipage}[h]{6.0in} 233Returns the cmm\_icc\_profile\_data member variable of the gs\_color\_space object. 234\end{minipage}\\ 235\\ 236 237\noindent gcmmhprofile\_t {\bf gsicc\_get\_profile\_handle\_buffer}(unsigned char *buffer);\\ 238 239\begin{minipage}[h]{6.0in} 240Returns the CMS handle to the ICC profile contained in the buffer. 241\end{minipage}\\ 242 243\singlespace 244 245\subsection{Link Cache} 246 247The Link Cache is a reference counted member variable of Ghostscript's imager state. Its function is to maintain a list of recently used links that had been provided by the CMS. Currently the cache is simply a linked list where each link has hash information that defines the link in terms of the source ICC profile, the destination ICC profile, and the rendering parameters. The Link Cache is allocated in stable GC memory. Operators that relate to the Link Cache are contained in the file gsicccache.c/h and include the following:\\ 248 249\singlespace 250 251\noindent gsicc\_link\_cache\_t* {\bf gsicc\_cache\_new}(gs\_memory\_t *memory);\\ 252 253\begin{minipage}[h]{6.0in} 254Creator for the Link Cache. 255\end{minipage}\\ 256\\ 257 258\noindent void {\bf gsicc\_init\_buffer}(gsicc\_bufferdesc\_t *buffer\_desc, unsigned char num\_chan, 259 unsigned char bytes\_per\_chan, bool has\_alpha, bool alpha\_first, 260 bool is\_planar, int plane\_stride, int row\_stride, int num\_rows, int 261 pixels\_per\_row);\\ 262 263\begin{minipage}[h]{6.0in} 264This is used to initialize a gsicc\_bufferdesc\_t object. Two of these objects are used to describe the format of the buffers that are used in transforming color data. 265\end{minipage}\\ 266\\ 267\newpage 268 269\noindent gsicc\_link\_t* {\bf gsicc\_get\_link}(gs\_imager\_state * pis, gs\_color\_space *input\_colorspace, 270 gs\_color\_space *output\_colorspace, 271 gsicc\_rendering\_param\_t *rendering\_params, gs\_memory\_t 272 *memory, bool include\_softproof);\\ 273 274\begin{minipage}[h]{6.0in} 275This returns the link given the input color space, the output color space, and the rendering intent. When the requester of the link is finished using the link, it should release the link. When a link request is made, the Link Cache will use the parameters to compute a hash code. This hash code is used to determine if there is already a link transform that meets the needs of the request. If there is not a link present, the Link Cache will obtain a new one from the CMS (assuming there is sufficient memory) updating the cache.\\ 276 277The linked hash code is a unique code that identifies the link for an input color space, an object type, a rendering intent and an output color space. The operation that does the merging of these four pieces of information can easily be altered to ignore object type and/or rendering intent if so desired.\\ 278 279Note, that the output color space can be different than the device space. This occurs for example, when we have a transparency blending color space that is different than the device color space. 280\end{minipage}\\ 281\\ 282 283\noindent void {\bf gsicc\_release\_link}(gsicc\_link\_t *icclink);\\ 284 285\begin{minipage}[h]{6.0in} 286 This is called to notify the cache that the requester for the link no longer needs it. 287 The link is reference counted, so that the cache knows when it is able to destroy 288 the link. The link is released through a call to the CMS. 289\end{minipage}\\ 290 291\singlespace 292 293\subsection{CMS} 294 295Ghostscript interfaces to the CMS through a single file. The file gsicc\_littlecms.c/h is a reference interface between littleCMS and Ghostscript. If a new library is used (for example, if littleCMS is replaced with Windows ICM on a Windows platform (giving Windows color system (WCS) access on Vista or System 7)), the interface of these functions will remain the same but internally they will need to be changed. Specifically, the functions are as follows:\\ 296 297\singlespace 298 299\noindent void {\bf gscms\_create}(void **contextptr);\\ 300 301\begin{minipage}[h]{6.0in} 302 This operation performs any initializations required for the CMS. 303\end{minipage}\\ 304\\ 305 306\noindent void {\bf gscms\_destroy}(void **contextptr);\\ 307 308\begin{minipage}[h]{6.0in} 309 This operation performs any cleanup required for the CMS. 310\end{minipage}\\ 311\\ 312 313\noindent gcmmhprofile\_t {\bf gscms\_get\_profile\_handle\_mem}(unsigned char *buffer, unsigned int 314input\_size);\\ 315 316\begin{minipage}[h]{6.0in} 317 This returns a profile handle for the profile contained in the specified buffer. 318\end{minipage}\\ 319\\ 320 321\noindent void {\bf gscms\_release\_profile}(void *profile);\\ 322 323\begin{minipage}[h]{6.0in} 324When a color space is removed or we are ending, this is used to have the CMS release the profile handles it has created. 325\end{minipage}\\ 326\\ 327 328\noindent int {\bf gscms\_get\_channel\_count}(gcmmhprofile\_t profile);\\ 329 330\begin{minipage}[h]{6.0in} 331 Provides the number of colorants associated with the ICC profile. 332\end{minipage}\\ 333\\ 334 335\noindent gcmmhlink\_t {\bf gscms\_get\_link}(gcmmhprofile\_t lcms\_srchandle, gcmmhprofile\_t 336lcms\_deshandle, gsicc\_rendering\_param\_t 337*rendering\_params, gsicc\_manager\_t *icc\_manager);\\ 338 339\begin{minipage}[h]{6.0in} 340This is the function that obtains the linkhandle from the CMS. The call gscms\_get\_link is usually called from the Link Cache. In the graphics library, calls are made to obtain links using gsicc\_get\_link, since the link may already be available. However, it is possible to use gscms\_get\_link to obtain linked transforms outside the graphics library. For example, this may be useful in the case of the XPS interpreter, where minor color management needs to occur to properly handle gradient stops. 341\end{minipage}\\ 342\\ 343 344\noindent gcmmhlink\_t {\bf gscms\_get\_link\_proof}(gcmmhprofile\_t lcms\_srchandle, gcmmhprofile\_t 345lcms\_deshandle, gcmmhprofile\_t lcms\_proofhandle, gsicc\_rendering\_param\_t *rendering\_params, gsicc\_manager\_t *icc\_manager);\\ 346 347\begin{minipage}[h]{6.0in} 348This function is similar to the above function but includes a proofing ICC profile. If the proofing profile is defined, then the output should appear as if it were printed on the device defined by the proofing profile. 349\end{minipage}\\ 350\\ 351 352\noindent void {\bf gscms\_release\_link}(gsicc\_link\_t *icclink);\\ 353 354\begin{minipage}[h]{6.0in} 355When a link is removed from the cache or we are ending, this is used to have the CMS release the link handles it has created. 356\end{minipage}\\ 357\\ 358 359\noindent void {\bf gscms\_transform\_color\_buffer}(gsicc\_link\_t *icclink, gsicc\_bufferdesc\_t 360*input\_buff\_desc, gsicc\_bufferdesc\_t 361*output\_buff\_desc, void *inputbuffer, void *outputbuffer);\\ 362 363\begin{minipage}[h]{6.0in} 364This is the function through which all color transformations will occur if they are to go through the CMS. This function will be called in the code anytime that we are transforming color from the current graphic state color to the Output Device color space or to the Blending Color Space, or out of the Blending color space to the Color Space of the parent layer in the transparency stack. Note that if the source hash code and the destination hash code are the same, the transformation will not occur as the source and destination color spaces are identical. This feature can be used to enable ``device colors'' to pass unmolested through the color processing. 365\end{minipage}\\ 366\\ 367 368\noindent void {\bf gscms\_transform\_color}(gsicc\_link\_t *icclink, void *inputcolor, void 369*outputcolor, int num\_bytes, void **contextptr);\\ 370 371\begin{minipage}[h]{6.0in} 372This is a special case where we desire to transform a single color. While it would be possible to use gscms\_transform\_color\_buffer for this operation, single color transformations are frequently required and it is possible that the CMS may have special optimized code for this operation. 373\end{minipage}\\ 374\\ 375 376\noindent int {\bf gscms\_transform\_named\_color}(gsicc\_link\_t *icclink, float tint\_value, const char*\\ 377 ColorName, gx\_color\_value device\_values[] );\\ 378 379\begin{minipage}[h]{6.0in} 380Get a device value for the named color. Since there exist named color ICC profiles and littleCMS supports them, the code in gsicc\_littlecms.c is designed to use that format. However, it should be noted that this object need not be an ICC named color profile but can be a proprietary type table. Some CMMs do not support named color profiles. In that case, or if the named color is not found, the caller should use an alternate tint transform or other method. If a proprietary format (nonICC) is being used to define named colors, this operator and gscms\_get\_name2device\_link given below must be implemented with that particular format. Note that we allow the passage of a tint value also. Currently the ICC named color profile does not provide tint related information, only a value for 100\% coverage. It is provided here for use in proprietary methods, which may be able to provide the desired effect. In gsicc\_littlecms.c, a direct tint operation will be applied to the returned device value. 381\end{minipage}\\ 382\\ 383 384\noindent void {\bf gscms\_get\_name2device\_link}(gsicc\_link\_t *icclink, gcmmhprofile\_t 385lcms\_srchandle, gcmmhprofile\_t lcms\_deshandle, gcmmhprofile\_t lcms\_proofhandle, 386gsicc\_rendering\_param\_t *rendering\_params, gsicc\_manager\_t *icc\_manager);\\ 387 388\begin{minipage}[h]{6.0in} 389This is the companion operator to gscms\_transform\_named\_color in that it provides the link transform that should be used when transforming named colors. Again, the file gsicc\_littlecms.c is designed to use ICC named color profiles. Other formats can be easily implemented. 390\end{minipage}\\ 391 392 393\singlespace 394 395\section{PDF and PS CIE color space handling} 396 397If a color space is a PDF or PostScript (PS) CIE color space type (other than ICC), these color spaces will be converted to appropriate ICC objects. The hash code associated with these objects will be based upon the PS or PDF objects as opposed to the created ICC data. Procedural sampling will be performed for the procedures found in PS. Since the blending color spaces are limited to ICC, device or CIE color spaces defined in PDF, the transformation of all to an ICC type is straight forward. The conversion from these spaces to ICC forms is contained in the file gsicc\_create.c. Since this file is only needed by the PS and PDF interpreter, it is contained in the psi subdirectory of Ghostscript's folder tree and is not needed for PCL or XPS builds. Performing this conversion, enables the ICC based CMS full control over all color management. To avoid frequent conversions due to frequent color space changes, these color spaces will be cached and indexed related to their resource IDs. This is the profile cache item that is indicated in Figure \ref{fig:ICC_ARCH}. In PDF, it is possible to define CIELAB color values directly. The ICC profile lab.icc contained in iccprofiles of Figure \ref{fig:ICC_ARCH} is used as the source ICC profile for color defined in this manner. Adjustments to the white point may be necessary depending upon the rendering intent. 398 399Note that if littleCMS is replaced, gsicc\_create.c still requires icc34.h, since it uses the type definitions in that file in creating the ICC profiles from the PS and PDF CIE color spaces. 400 401\section{Device Interaction} 402 403From Figure \ref{fig:ICC_ARCH}, it is clear that the device can communicate to the graphics library its ICC profiles. Depending upon the settings of the device (e.g. paper type, ink, driver settings) it may provide a different profile as well as indicate a desired rendering intent. Unless overridden by command line arguments, this information will be used to populate the ICC manager's Device Profile and Named Color Profile entries. Currently, this portion of the architecture is under development. 404 405\section{DeviceN Color Spaces} 406 407DeviceN and Separation colors are handled differently depending upon the source PDL that is being processed. In Microsoft's XPS format, all input DeviceN or Separation type colors are required to have an associated ICC profile. If one is not provided, then a SWOP CMYK profile is assumed for the first four colorants and the remaining colorants are ignored. With PDF DeviceN or Separation colors, the document defines a tint transform and an alternate color space, which could be any of the CIE (e.g. CalGray, CalRGB, Lab, ICC) or device (e.g. Gray, RGB, CMYK) color spaces. If the input is PDF or PS and the output device does not understand the colorants defined in the DeviceN color space, then the colors will be transformed to the alternate color space and color managed from there. 408 409For cases when the device {\bf does} understand the spot colorants of the DeviceN color space, the preferred handling of DeviceN varies. Many prefer to color manage the CMYK components with a defined CMYK profile, while the other spot colorants pass through unmolested. This will be the default manner by which Ghostscript will handle DeviceN input colors. In other words, if the device profile is set to a particular CMYK profile, and the output device is a separation device, which can handle all spot colors, then the CMYK process colorants will be color managed, but the other colorants will not be managed. If it is desired that the CMYK colorants not be altered also, it will be possible to achieve this by having the source and destination ICC profiles the same. This will result in an identity transform, which will not be used when processing the CMYK colorants. 410 411It should be noted that an ICC profile can define color spaces with up to 15 colorants. For a device that has 15 or fewer colorants, it is possible to provide an ICC profile for such a device. In this case, all the colorants will be color managed through the ICC profile. For cases beyond 15, the device will be doing direct printing of the DeviceN colors outside of the 15 colorants. 412 413\begin{figure}[h] 414 \begin{center} 415 % \leavevmode \epsfysize=3.0in 416\includegraphics*[width=6.0in]{figures/PDF_Spec.eps} 417 \end{center} 418 \caption{PDF Color Specification} 419 \label{fig:PDF_SPEC} 420\end{figure} 421 422\begin{figure}[h] 423 \begin{center} 424 % \leavevmode \epsfysize=3.0in 425\includegraphics*[width=6.0in]{figures/PDF_Render.eps} 426 \end{center} 427 \caption{PDF Color Rendering} 428 \label{fig:PDF_RENDER} 429\end{figure} 430 431\begin{figure}[h] 432 \begin{center} 433 % \leavevmode \epsfysize=3.0in 434\includegraphics*[width=6.0in]{figures/PS_Spec.eps} 435 \end{center} 436 \caption{PostScript Color Specification} 437 \label{fig:PS_SPEC} 438\end{figure} 439 440\begin{figure}[h] 441 \begin{center} 442 % \leavevmode \epsfysize=3.0in 443\includegraphics*[width=6.0in]{figures/PS_Render.eps} 444 \end{center} 445 \caption{PostScript Color Rendering} 446 \label{fig:PS_RENDER} 447\end{figure} 448 449\begin{figure}[h] 450 \begin{center} 451 % \leavevmode \epsfysize=3.0in 452\includegraphics*[width=6.0in]{figures/XPS_Vector_Color.eps} 453 \end{center} 454 \caption{XPS Vector Color Specification} 455 \label{fig:XPS_VECTOR} 456\end{figure} 457 458\begin{figure}[h] 459 \begin{center} 460 % \leavevmode \epsfysize=3.0in 461\includegraphics*[width=6.0in]{figures/XPS_Integer_Gray_RGB_Image.eps} 462 \end{center} 463 \caption{XPS Integer RGB and Grayscale Image Specification} 464 \label{fig:XPS_INTEGER_RGB} 465\end{figure} 466 467\begin{figure}[h] 468 \begin{center} 469 % \leavevmode \epsfysize=3.0in 470\includegraphics*[width=6.0in]{figures/XPS_RGB_Image_Float.eps} 471 \end{center} 472 \caption{XPS Float or Fixedpoint RGB Image Color Specification} 473 \label{fig:XPS_FLOAT_IMAGE} 474\end{figure} 475 476\begin{figure}[h] 477 \begin{center} 478 % \leavevmode \epsfysize=3.0in 479\includegraphics*[width=6.0in]{figures/XPS_DeviceN.eps} 480 \end{center} 481 \caption{XPS CMYK and N-Channel (N$>$3) Image Color Specification} 482 \label{fig:XPS_DEVICEN} 483\end{figure} 484 485\begin{figure}[h] 486 \begin{center} 487 % \leavevmode \epsfysize=3.0in 488\includegraphics*[width=6.0in]{figures/XPS_Render.eps} 489 \end{center} 490 \caption{XPS Rendering Side. Note that ALL colors are defined by an ICC color space at this point.} 491 \label{fig:XPS_RENDER} 492\end{figure} 493 494\clearpage 495 496\begin{thebibliography}{99} 497 498\bibitem{ICC} Specification ICC.1:2004-10 (Profile version 4.2.0.0) Image technology colour management - Architecture, profile format, and data structure. 499(http://www.color.org/ICC1v42\_2006-05.pdf), Oct. 2004. 500 501\bibitem{PS} PostScript� Language Reference Third Edition, Adobe Systems Incorporated, Addison-Wesley Publishing, (http://partners.adobe.com/public/developer/ps/index\_specs.html) 502Reading Massachusetts, 1999. 503 504\bibitem{PDF} PDF Reference Sixth Edition Ver. 1.7, Adobe Systems Incorporated, (http://www.adobe.com/devnet/pdf/pdf\_reference.html), November 2006. 505 506\bibitem{XPS} XML Paper Specification Ver. 1.0, Microsoft Corporation, (http://www.microsoft.com/whdc/xps/xpsspec.mspx), 2006. 507 508\bibitem{PCL} PCL5 Printer Language Technical Reference Manual, Hewlett Packard, (http://h20000.www2.hp.com/bc/docs/support/SupportManual/bpl13210/bpl13210.pdf), October 1992. 509 510\end{thebibliography} 511 512\vspace*{4.25in} 513Copyright (c) 2009, Artifex Software Inc. All rights reserved. 514 515 516\end{document} 517