Creating OWconfig File Entries
You must include OWconfig library in the CMM linking. To link in this library, enter -lowconfig on the link command line . The OWconfig library is bundled with Solaris in /usr/openwin/lib/libowconfig.so. It provides routines to access the OWconfig file, which gets the name of the CMM class derivitive you want to dynamically load.
To advertise its existence of your CMM class derivative to the KCMS framework, you must add the name of the derivitive to the OWconfig file.
A generic OWconfig entry looks like this:
class="KCS_IO" name="solf" kcsLoadableModule="kcsSUNWIOsolf.so.1"; |
Table 2-3 describes each field.
Table 2-3 OWconfig File Entry Description|
OWconfig File Entry |
Description |
|---|---|
|
class |
KCS_<class name>. |
|
name |
Four- or eight-character identifier that matches the identifier in your code. |
|
kcsLoadableModule |
Entire module name. |
The above is just an example of the OWconfig file structure. You need to add an OWconfig file entry for each class you derive from or extend in your CMM. Examples of these entries are shown in the following paragraphs.
KcsIO Example
If you derive from the KcsIO class, you need to provide a KcsIO class entry such as the example entries below:
Note the name strings in the above examples. The KcsProfileType enumeration in kcstypes.h contains a type field that is a 4-character array described in hexadecimal form as a long, for example:
The OWconfig library turns the type field back into a string corresponding to the name field entry and searches all of the appropriate OWconfig class entries for that string.
KcsProfile Example
If you derive from the KcsProfile class, you need to provide a KcsProfile class entry such as the example entries below:
The key to loading a new version is the CMM Id (also called CMM Type), which is contained in bytes 4 through 7 in the ICC profile header). (See "ICC Profile Header" for details.) If there is not a match, the default entry dflt is used. You must load the proper CMM Id into the new profile's CMM Id attribute field for recognition of the module.
The default loadable KcsProfile module is the Solaris-supplied default.
The KcsProfile class is the base class that can contain transformations (KcsXform class) and a profile format (KcsProfileFormat class). Since the Kodak KcsProfile class is built into the library, you can use this mechanism to extend the calibration and characterization interface.
KcsProfileFormat Example
If you derive from the KcsProfileFormat class, you need to provide a KcsProfileFormat class entry such as the example entries below:
The profile format is determined from the profile file signature (also known as the magic number), which is contained in bytes 36-39 in the ICC profile header), and CMM Id (bytes 4-7 in the header). (See "ICC Profile Header".) A check is performed to ensure that an ICC profile uses the magic number of the file. If another format is used, the magic number is used to load the module.
All profiles that are ICC profile format files should have a magic number equal to acsp, and they must have the ICC header included. The CMM Id is used to match the profile format with the correct derivative. If no match is found, the default entry (dflt) is used; therefore, you can use the supplied default profile format class for ICC profiles.
The name field syntax is: <Profile magic number><CMM Id>
The OWconfig file entry must match the resulting name. This also gives color management vendors the opportunity to support pre-ICC format profiles, provided they include the ICC header.
KcsXform Example
If you derive from the KcsXForm class, you need to provide a KcsXForm class entry such as the example entries below:
The name field is a combination of a unique 4-character transform identifier and the CMM Id. (The transform identifier must be registered with the ICC if the profile and CMM are to be made available to the public.) The library turns name back into a string and searches all of the appropriate OWconfig class entries.
Inside an ICC profile, the type of transform is defined by a type identifier that indicates whether it is an 8- or 16-multi function table, indicated by the signature element of either the Lut8Type (mft1) or Lut16Type (mft2). Default values have been supplied for these cases: mft1dflt and mft2dflt.
KcsStatus Example
If you extend the KcsStatus class, you need to provide a KcsStatus class entry such as the example below:
#Extending error messages class="KCS_STAT" name-"solm" kcsLoadableModule="kcsSUNWSTATsolm.so.1"; |
The name field is a 4-character string that uniquely identifies your set of error and warning messages.
To add your own error messages, supply a single "C" routine that translates your error value into an error string. Also supply a messages.po file for localization purposes. See Chapter 8, KcsStatus Extension for detailed information.
If an OwnerId variable is set with the status message, the KcsStatus class dynamically loads the matching OwnerId that was set by the dynamically loaded class. The OwnerID is described in Chapter 8, KcsStatus Extension.
- © 2010, Oracle Corporation and/or its affiliates