\documentclass[12pt,notitlepage]{article}
%\usepackage{osa2}
%\usepackage{overcite}  %% PRODUCES SUPERSCRIPT REFERENCE CITATIONS
%\usepackage[comma,sort&compress,nonamebreak]{natbib}
%\bibpunct{[}{]}{,}{n}{}{,}
%\bibpunct{\textsuperscript{}}{\textsuperscript{}}{,}{s}{,}{,}
%\citestyle{nature}
\usepackage{epsfig,url}
\urlstyle{same}

\oddsidemargin      0in
\evensidemargin     0in
\setlength{\paperheight}{11in}%
\setlength{\paperwidth}{8.5in}%
\setlength{\textwidth}{\paperwidth}%
% subtract for the 1" top/bottom margins
\addtolength{\textwidth}{-2.0in}%
\setlength{\textheight}{\paperheight}%
\addtolength{\textheight}{-3.0in}%

\usepackage{setspace}
\usepackage{amsmath}
\usepackage{color}
\usepackage{hyperref}
\usepackage[ansinew]{inputenc}
\pagestyle{myheadings} \markboth{ Artifex Software Inc. www.artifex.com }{Artifex Software Inc. www.artifex.com}

\begin{document}

\begin{titlepage}

\begin{center}{\huge \bf Ghostscript Color Management\\} \vspace{0.5in} {\Large Michael J.
Vrhel, Ph.D.\\} {\Large Artifex Software\\} {\Large 7 Mt. Lassen Drive, A-134\\} {\Large San Rafael, CA 94903, USA\\}
{\Large www.artifex.com\\}
\end{center}
\vspace*{0.5in}
\begin{abstract}
This 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.
\end{abstract}
\begin{center}
\vspace*{0.25in}
Revision 1.0
\vspace*{0.25in}
\begin{figure}[h]
    \begin{center}
\includegraphics*[width=1.5in]{figures/Ghost.eps}
    \end{center}
\end{figure}

\end{center}

\end{titlepage}

\renewcommand{\baselinestretch}{1.67}\normalsize
%\maketitle

\clearpage

\singlespace

\section{Introduction}

This 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.

The 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

Today, 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.

Many 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.

Given these many concerns, the requirements of the architecture are as follows:
\begin{itemize}
\item	It must be easy to introduce a new CMS into the build of Ghostscript.
\item	There must be objects/methods to manage the ICC profiles and the linked transforms.
\item	It must be possible to define all color spaces in terms of ICC profiles.
\item	It must be possible to have the CMS operate on buffers of data.
\item	Devices can communicate ICC profiles and have their ICC profile set.
\item	It must work with PostScript color management definitions.
\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).
\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.
\item	It must be designed to operate efficiently in a multithreaded environment.
\end{itemize}

Figure \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).

In 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.

\begin{figure}
    \begin{center}
  %  \leavevmode \epsfysize=3.0in
\includegraphics*[width=6.0in]{figures/Overview.eps}
    \end{center}
   \caption{Graphical Overview of ICC Architecture}
    \label{fig:ICC_ARCH}
\end{figure}

\section{PDL Color Definitions and ICC Profiles}

To 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.

To 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.

The 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}.

\section{Usage}

The code is currently available for checkout with SVN on a branch named icc\_work of the main trunk of Ghostscript.  The specific URL is\\

\textcolor{blue}{\href{http://svn.ghostscript.com/ghostscript/branches/icc_work}{http://svn.ghostscript.com/ghostscript/branches/icc\_work}}
\\

\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.

The 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.\\

\textcolor{red}{-sDefaultGrayProfile=my\_gray\_profile.icc}\\

\textcolor{red}{-sDefaultRGBProfile=my\_rgb\_profile.icc}\\

\textcolor{red}{-sDefaultCMYKProfile=my\_cmyk\_profile.icc}\\

In 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\\

\textcolor{red}{-sOutputICCProfile=my\_device\_profile.icc}\\

A 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\\

\textcolor{red}{-sICCProfilesDir=c:/my\_icc\_profiles/}\\

Warnings 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\\

\textcolor{red}{-sProofProfile=my\_proof\_profile.icc}\\

\textcolor{red}{-sNamedProfile=my\_namedcolor\_profile.icc}\\

\textcolor{red}{-sDeviceLinkProfile=my\_link\_profile.icc}\\

Setting 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

Finally, 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.

\newpage

\section{Overview of objects and methods}

At this point, let us go into further detail of the architecture.

\subsection{ICC Manager}

The ICC Manager is a reference counted member variable of Ghostscript's imager state.  Its functions are to:

\begin{itemize}
\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.
\item Store the required profile information for the output device.
\item Store the optional profile information related to named colors (if set), the proofing profile (if set) a final output link profile (if set).
\item Store the directory be used to search for ICC profiles specified for the above objects.
\end{itemize}

The 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.\\

\noindent typedef struct gsicc\_manager\_s \{

\begin{tabular}{lll}
  &       cmm\_profile\_t *device\_named;   & 	\textcolor{green}{/* The named color profile for the device */}  \\
  &       cmm\_profile\_t *default\_gray;   & 	\textcolor{green}{/* Default gray profile for device gray */}   \\
  &       cmm\_profile\_t *default\_rgb;    &	 \textcolor{green}{/* Default RGB profile for device RGB */}    \\
  &       cmm\_profile\_t *default\_cmyk;   & 	\textcolor{green}{/* Default CMYK profile for device CMKY */} \\
  &       cmm\_profile\_t *proof\_profile;  & 	\textcolor{green}{/* Profiling profile */} \\
  &       cmm\_profile\_t *output\_link;    & 	\textcolor{green}{/* Output device Link profile */}    \\
  &       cmm\_profile\_t *device\_profile; & 	\textcolor{green}{/* The actual profile for the device */}    \\
  &       cmm\_profile\_t *lab\_profile;    &  \textcolor{green}{/* Colorspace type ICC profile from LAB to LAB */}   \\
  &       char *profiledir;              	&	 \textcolor{green}{/* Directory used in searching for ICC profiles */}    \\
  &       uint namelen; & \\
  &       gs\_memory\_t *memory;    & \\
  &       rc\_header rc; &
\end{tabular}
\noindent  \} gsicc\_manager\_t;\\

\noindent Operators that relate to the ICC Manager are contained in the file gsiccmanage.c/h and include the following:\\

\singlespace
\noindent int {\bf gsicc\_init\_device\_profile}(gs\_state * pgs, gx\_device * dev);\\

\begin{minipage}[h]{6.0in}

This initializes the device\_profile member variable based upon the properties of the device.  The device may have a profile defined in its
dev$\rightarrow$color\_info.icc\_profile member variable.  If it does not, then a default profile will be assigned to the device.
\end{minipage}\\
\\

\noindent int {\bf gsicc\_set\_profile}(const gs\_imager\_state * pis, const char *pname, int namelen, \\gsicc\_profile\_t defaulttype);\\
\\

\begin{minipage}[h]{6.0in}
This is used to set all the other profile related member variables in the ICC Manager.  The member variable to set is specified by defaulttype.
\end{minipage}\\
\\

\noindent void {\bf gsicc\_set\_icc\_directory}(const gs\_imager\_state *pis, const char* pname, int namelen);\\

\begin{minipage}[h]{6.0in}
This is used to set the directory for finding the ICC profiles specified by \\ gsicc\_set\_profile.
\end{minipage}\\
\\

\noindent gsicc\_manager\_t* {\bf gsicc\_manager\_new}(gs\_memory\_t *memory);\\
	
\begin{minipage}[h]{6.0in}
Creator for the ICC Manager.
\end{minipage}\\
\\

\noindent cmm\_profile\_t* {\bf gsicc\_profile\_new}(stream *s, gs\_memory\_t *memory, const char* pname, int namelen);\\

\begin{minipage}[h]{6.0in}
Returns 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.
\end{minipage}\\
\\

\newpage

\noindent int {\bf gsicc\_set\_gscs\_profile}(gs\_color\_space *pcs, cmm\_profile\_t *icc\_profile, \\gs\_memory\_t * mem);\\

\begin{minipage}[h]{6.0in}
Sets the member variable cmm\_icc\_profile\_data of the gs\_color\_space object (pointed to by pcs) to icc\_profile.
\end{minipage}\\
\\

\noindent cmm\_profile\_t* {\bf gsicc\_get\_gscs\_profile}(gs\_color\_space *gs\_colorspace, gsicc\_manager\_t *icc\_manager);\\

\begin{minipage}[h]{6.0in}
Returns the cmm\_icc\_profile\_data member variable of the gs\_color\_space object.
\end{minipage}\\
\\

\noindent gcmmhprofile\_t {\bf gsicc\_get\_profile\_handle\_buffer}(unsigned char *buffer);\\

\begin{minipage}[h]{6.0in}
Returns the CMS handle to the ICC profile contained in the buffer.
\end{minipage}\\

\singlespace

\subsection{Link Cache}

The 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:\\

\singlespace

\noindent gsicc\_link\_cache\_t* {\bf gsicc\_cache\_new}(gs\_memory\_t *memory);\\

\begin{minipage}[h]{6.0in}
Creator for the Link Cache.
\end{minipage}\\
\\

\noindent void {\bf gsicc\_init\_buffer}(gsicc\_bufferdesc\_t *buffer\_desc, unsigned char num\_chan,
                                     unsigned char bytes\_per\_chan, bool has\_alpha, bool alpha\_first,
                                     bool is\_planar, int plane\_stride, int row\_stride, int num\_rows, int
                                     pixels\_per\_row);\\

\begin{minipage}[h]{6.0in}
This 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.
\end{minipage}\\
\\
\newpage

\noindent gsicc\_link\_t* {\bf gsicc\_get\_link}(gs\_imager\_state * pis, gs\_color\_space  *input\_colorspace,
                                               gs\_color\_space *output\_colorspace,
                                               gsicc\_rendering\_param\_t *rendering\_params, gs\_memory\_t
                                               *memory, bool include\_softproof);\\

\begin{minipage}[h]{6.0in}
This 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.\\

The 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.\\

Note, 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.
\end{minipage}\\
\\

\noindent void {\bf gsicc\_release\_link}(gsicc\_link\_t *icclink);\\

\begin{minipage}[h]{6.0in}
	This is called to notify the cache that the requester for the link no longer needs it.  	
	The link is reference counted, so that the cache knows when it is able to destroy
	the link.  The link is released through a call to the CMS.
\end{minipage}\\

\singlespace

\subsection{CMS}

Ghostscript 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:\\

\singlespace

\noindent void {\bf gscms\_create}(void **contextptr);\\

\begin{minipage}[h]{6.0in}
	This operation performs any initializations required for the CMS.
\end{minipage}\\
\\

\noindent void {\bf gscms\_destroy}(void **contextptr);\\

\begin{minipage}[h]{6.0in}
	This operation performs any cleanup required for the CMS.
\end{minipage}\\
\\

\noindent gcmmhprofile\_t {\bf gscms\_get\_profile\_handle\_mem}(unsigned char *buffer, unsigned int
input\_size);\\

\begin{minipage}[h]{6.0in}
	This returns a profile handle for the profile contained in the specified buffer.
\end{minipage}\\
\\

\noindent void {\bf gscms\_release\_profile}(void *profile);\\

\begin{minipage}[h]{6.0in}
When a color space is removed or we are ending, this is used to have the CMS release the profile handles it has created.
\end{minipage}\\
\\

\noindent int {\bf gscms\_get\_channel\_count}(gcmmhprofile\_t profile);\\

\begin{minipage}[h]{6.0in}
	Provides the number of colorants associated with the ICC profile.
\end{minipage}\\
\\

\noindent gcmmhlink\_t {\bf gscms\_get\_link}(gcmmhprofile\_t  lcms\_srchandle, gcmmhprofile\_t
lcms\_deshandle, gsicc\_rendering\_param\_t
*rendering\_params, gsicc\_manager\_t *icc\_manager);\\

\begin{minipage}[h]{6.0in}
This 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.
\end{minipage}\\
\\

\noindent gcmmhlink\_t {\bf gscms\_get\_link\_proof}(gcmmhprofile\_t  lcms\_srchandle, gcmmhprofile\_t
lcms\_deshandle, gcmmhprofile\_t lcms\_proofhandle, gsicc\_rendering\_param\_t *rendering\_params, gsicc\_manager\_t *icc\_manager);\\

\begin{minipage}[h]{6.0in}
This 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.
\end{minipage}\\
\\

\noindent void {\bf gscms\_release\_link}(gsicc\_link\_t *icclink);\\

\begin{minipage}[h]{6.0in}
When 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.
\end{minipage}\\
\\

\noindent void {\bf gscms\_transform\_color\_buffer}(gsicc\_link\_t *icclink, gsicc\_bufferdesc\_t
*input\_buff\_desc,  gsicc\_bufferdesc\_t
*output\_buff\_desc, void *inputbuffer, void *outputbuffer);\\

\begin{minipage}[h]{6.0in}
This 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.
\end{minipage}\\
\\

\noindent void {\bf gscms\_transform\_color}(gsicc\_link\_t *icclink,  void *inputcolor, void
*outputcolor, int num\_bytes, void **contextptr);\\

\begin{minipage}[h]{6.0in}
This 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.
\end{minipage}\\
\\

\noindent int {\bf gscms\_transform\_named\_color}(gsicc\_link\_t *icclink,  float tint\_value, const char*\\
    ColorName,  gx\_color\_value device\_values[] );\\

\begin{minipage}[h]{6.0in}
Get 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.
\end{minipage}\\
\\

\noindent void {\bf gscms\_get\_name2device\_link}(gsicc\_link\_t *icclink, gcmmhprofile\_t
lcms\_srchandle, gcmmhprofile\_t lcms\_deshandle, gcmmhprofile\_t lcms\_proofhandle,
gsicc\_rendering\_param\_t *rendering\_params, gsicc\_manager\_t *icc\_manager);\\

\begin{minipage}[h]{6.0in}
This 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.
\end{minipage}\\


\singlespace

\section{PDF and PS CIE color space handling}

If 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.

Note 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.

\section{Device Interaction}

From 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.

\section{DeviceN Color Spaces}

DeviceN 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.

For 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.

It 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.

\begin{figure}[h]
    \begin{center}
  %  \leavevmode \epsfysize=3.0in
\includegraphics*[width=6.0in]{figures/PDF_Spec.eps}
    \end{center}
   \caption{PDF Color Specification}
    \label{fig:PDF_SPEC}
\end{figure}

\begin{figure}[h]
    \begin{center}
  %  \leavevmode \epsfysize=3.0in
\includegraphics*[width=6.0in]{figures/PDF_Render.eps}
    \end{center}
   \caption{PDF Color Rendering}
    \label{fig:PDF_RENDER}
\end{figure}

\begin{figure}[h]
    \begin{center}
  %  \leavevmode \epsfysize=3.0in
\includegraphics*[width=6.0in]{figures/PS_Spec.eps}
    \end{center}
   \caption{PostScript Color Specification}
    \label{fig:PS_SPEC}
\end{figure}

\begin{figure}[h]
    \begin{center}
  %  \leavevmode \epsfysize=3.0in
\includegraphics*[width=6.0in]{figures/PS_Render.eps}
    \end{center}
   \caption{PostScript Color Rendering}
    \label{fig:PS_RENDER}
\end{figure}

\begin{figure}[h]
    \begin{center}
  %  \leavevmode \epsfysize=3.0in
\includegraphics*[width=6.0in]{figures/XPS_Vector_Color.eps}
    \end{center}
   \caption{XPS Vector Color Specification}
    \label{fig:XPS_VECTOR}
\end{figure}

\begin{figure}[h]
    \begin{center}
  %  \leavevmode \epsfysize=3.0in
\includegraphics*[width=6.0in]{figures/XPS_Integer_Gray_RGB_Image.eps}
    \end{center}
   \caption{XPS Integer RGB and Grayscale Image Specification}
    \label{fig:XPS_INTEGER_RGB}
\end{figure}

\begin{figure}[h]
    \begin{center}
  %  \leavevmode \epsfysize=3.0in
\includegraphics*[width=6.0in]{figures/XPS_RGB_Image_Float.eps}
    \end{center}
   \caption{XPS Float or Fixedpoint RGB Image Color Specification}
    \label{fig:XPS_FLOAT_IMAGE}
\end{figure}

\begin{figure}[h]
    \begin{center}
  %  \leavevmode \epsfysize=3.0in
\includegraphics*[width=6.0in]{figures/XPS_DeviceN.eps}
    \end{center}
   \caption{XPS CMYK and N-Channel (N$>$3) Image Color Specification}
    \label{fig:XPS_DEVICEN}
\end{figure}

\begin{figure}[h]
    \begin{center}
  %  \leavevmode \epsfysize=3.0in
\includegraphics*[width=6.0in]{figures/XPS_Render.eps}
    \end{center}
   \caption{XPS Rendering Side.  Note that ALL colors are defined by an ICC color space at this point.}
    \label{fig:XPS_RENDER}
\end{figure}

\clearpage

\begin{thebibliography}{99}

\bibitem{ICC} Specification ICC.1:2004-10 (Profile version 4.2.0.0) Image technology colour management - Architecture, profile format, and data structure.
(http://www.color.org/ICC1v42\_2006-05.pdf), Oct. 2004.

\bibitem{PS} PostScript Language Reference Third Edition, Adobe Systems Incorporated, Addison-Wesley Publishing, (http://partners.adobe.com/public/developer/ps/index\_specs.html)
Reading Massachusetts, 1999.

\bibitem{PDF} PDF Reference Sixth Edition Ver. 1.7, Adobe Systems Incorporated, (http://www.adobe.com/devnet/pdf/pdf\_reference.html), November 2006.

\bibitem{XPS} XML Paper Specification Ver. 1.0, Microsoft Corporation, (http://www.microsoft.com/whdc/xps/xpsspec.mspx), 2006.

\bibitem{PCL} PCL5 Printer Language Technical Reference Manual, Hewlett Packard, (http://h20000.www2.hp.com/bc/docs/support/SupportManual/bpl13210/bpl13210.pdf), October 1992.

\end{thebibliography}

\vspace*{4.25in}
Copyright (c) 2009, Artifex Software Inc. All rights reserved.


\end{document}