![]() |
PATH![]() |
![]() ![]() |
This section describes some of the processes your CMM can perform in response to the following ColorSync Manager requests that it must handle:
The Component Manager calls your CMM with an initialization request, setting the what field of the ComponentParameters data structure to kNCMMInit . In most cases the Component Manager calls your CMM with an initialization request before it calls your CMM with any other ColorSync Manager requests.
In response to this request, your CMM should call its
NCMInit
initialization subroutine. For a description of the function prototype your initialization subroutine must adhere to, see
NCMInit
.
Using the private storage you allocated in response to the open request, your initialization subroutine should instantiate any private data it needs for the component instance. Before your entry point function returns a function result to the Component Manager, your subroutine should store any profile information it requires. In addition to the standard profile information, you should store the profile header's quality flags setting, the profile size, and the rendering intent. After you return control to the Component Manager, you cannot use the profile references again.
The kNCMMInit request gives you the opportunity to examine the profile contents before storing them. If you do not support some aspect of the profile, then you should return an unimplemented error in response to this request. For example, if your CMM does not implement multichannel color support, you should return an "unimplemented" error at this point.
The Component Manager may call your CMM with the kNCMMInit request code multiple times after it calls your CMM with a request to open the CMM. For example, it may call your CMM with an initialization request once with one pair of profiles and then again with another pair of profiles. For each call, you need to reinitialize the storage based on the content of the current profiles.
Your CMM should support all seven classes of profiles defined by the ICC. For the constants used to specify the seven classes of profiles, see Profile Class .
When a ColorSync-supportive application or device driver calls the CWMatchColors function for your CMM to handle, the Component Manager calls your CMM with a color-matching session request, setting the what field of the ComponentParameters data structure to kCMMMatchColors and passing you a list of colors to match . The Component Manager may also call your CMM with this request code to handle other cases, for example, when a ColorSync-supportive program calls the CWMatchPixMap function.
Before it calls your CMM with this request, the Component Manager calls your CMM with one of the initialization requests-- kCMMInit , kNCMMInit , or kCMMConcatInit --passing to your CMM in the params field of the ComponentParameters data structure the profiles for the color-matching session.
In response to the
kCMMMatchColors
request, your CMM should call its
CMMatchColors
subroutine by calling the Component Manager's
CallComponentFunctionWithStorage
function and passing it a handle to the storage for this component instance, the
ComponentParameters
data structure, and the address of your
CMMatchColors
subroutine. For a description of the function prototype to which your subroutine must adhere, see
CMMatchColors
.
The parameters passed to your CMM for this request include an array of type CMColor containing the list of colors to match and a one-based count of the number of colors in the list.
To handle this request, your CMM must match the source colors in the list to the color gamut of the destination profile, replacing the color value specifications in the
myColors
array with the matched colors specified in the destination profile's data color space. You should use the rendering intent and the quality flag setting of the source profile in matching the colors. For a description of the color list array data structure, see
CMColor
.
When a ColorSync-supportive application or device driver calls the CWCheckColors function for your CMM to handle, the Component Manager calls your CMM with a color gamut-checking session request, setting the what field of the ComponentParameters data structure to kCMMCheckColors and passing you a list of colors to check.
Before the Component Manager calls your CMM with the kCMMCheckColors request, it calls your CMM with one of the initialization requests-- kCMMInit , kNCMMInit , or kCMMConcatInit --passing to your CMM in the params field of the ComponentParameters data structure the profiles for the color gamut-checking session.
I
n response to the
kCMMCheckColors
request, your CMM should call its
CMCheckColors
subroutine. For example, if you use the Component Manager's
CallComponentFunctionWithStorage
function, you pass it a handle to the storage for this component instance, the
ComponentParameters
data structure, and the address of your
CMCheckColors
subroutine. For a description of the function prototype to which your subroutine must adhere, see
CMCheckColors
.
In addition to the handle to the private storage containing the profile data, the CallComponentFunctionWithStorage function passes to your CMCheckColors subroutine an array of type CMColor containing the list of colors to gamut check, a one-based count of the number of colors in the list, and an array of longs.
To handle this request, your CMM should test the given list of colors against the gamut specified by the destination profile to determine whether the colors fall within a destination device's color gamut. For each source color in the list that is out of gamut, you must set the corresponding bit in the result array to 1.