Putting It All Together

In This Chapter

This chapter threads together all the steps involved in using the KCMS test suite with your CMM. The chapter refers you to the appropriate KCMS documentation for details.

Development Environment Requirements

The KCMS packages are automatically placed in a protected directory when you load them with the pkgadd(3) command. Copy the packages to a writable directory for development use.

To compile programs, you must use version 4.2 of the Sun™ Visual Workshop™ C++ compiler, which is included with Sun Visual Workshop C++ 3.0.

Creating Your CMM

The KCMS CMM Developer's Guide and the KCMS CMM Reference Manual are your primary sources of information on how to create a CMM.

Setting Up Your CMM

Guidelines for setting up your CMM are described in detail in the KCMS CMM Developer's Guide. To set up your CMM,

1. Name your CMM according to the guidelines in Chapter 2, "CMM: A Runtime Derivative," in the KCMS CMM Developer's Guide. The section entitled "Configuration Requirements" explains what you need to know to load your CMM dynamically, including how to name it and how to update the OWconfig file.

2. Install your CMM according to the guidelines in the same chapter and section referenced in step 1.

3. Create and name the profile(s) for your CMM according to the guidelines in Chapter 2, "CMM: A Runtime Derivative," in the KCMS CMM Developer's Guide. The section entitled "Profiles" describes the ICC profile format and explains how to name profiles.

4. Install the profile so the KCMS framework can find it by following the guidelines in the same chapter and section referenced in step 3. Also install those profiles you want to use in the test suite in the kcmstest/profiles directory (see Installing Scripts and Profiles) or create a link to them.

Creating Test Scripts

If the test scripts that are packaged with the KCMS DDK are not adequate to test specific features of your custom CMM, you may decide to edit them. If you make any changes (change the names of, add, or delete scripts from the list in icc.ini file or customize the contents of scripts), you may need to create an alternate initialization file or run selected scripts. For details, see Chapter 2, Running KCMS Test Scripts in this guide.

The test scripts you create must follow the guidelines for using KCMS functions as described in the SDK manual KCMS Application Developer's Guide. For example, to evaluate profiles used by your CMM, your script first must connect profiles. Prior to connecting profiles, it must create or load profiles. Keep in mind that the test suite can only test attributes it knows about. If your profiles use new attributes, the test scripts cannot test them. For examples of how to set attribute values, see Chapter 5, Setting Attributes.

Installing Scripts and Profiles

So that the kcmstest command can find them, you must install all test scripts in the kcmstest/script directory. Install all profiles you want to use in the test suite in the kcmstest/profiles directory. (See Required File Hierarchy for a description of the KCMS test suite directory hierarchy.) Note that this profile installation is a separate installation from the one to set up your CMM (described in Setting Up Your CMM.)

Note - You may choose to install links to the location of your profiles.

Testing and Inspecting Results

Follow the guidelines for running the test scripts described in Chapter 2, Running KCMS Test Scripts. If you just plan to run a few scripts, you can use the kcms_qatest command with command options. See Using kcmstest To Run Test Scripts in Chapter 2. Alternately, if you plan to run a large batch of scripts, the chapter suggests that you use the automated test scripts to do so. See Using Automated Script Files To Run Test Scripts in Chapter 2.

Checking Status Codes

When you have run the scripts, inspect the log file(s).

In Chapter 2, "Running KCMS Test Scripts," Example 2-3 shows the log file output for the script shown in Example 2-2 in that same chapter. Status codes return the value 0 if a command completes successfully. Some scripts, however, expect an error to be returned. You can use the XStatus keyword to test for error conditions you expect to occur.

The IC_evalerr.scr test script, for example, creates test conditions in which the EVAL: command generates errors. The EVAL: command includes the optional keyword XStatus for reporting expected errors. Code example 5-1 is an excerpt from the IC_evalerr.scr script. The example shows two EVAL: commands that will generate errors because of incorrect or missing information. In each case, XStatus is set to the value 4024 ("KCS_PROF_NO_DATA_SUPPORT_4_REQUEST")

See Appendix A, Status Codes for a list of all the status strings and their values. You also can find status codes and strings in the header file kcsstats.h. For additional information on the meaning of status codes, see Chapter 6, "Warnings and Error Messages," in the SDK manual KCMS Application Developer's Guide.

Example 6-1 Using XStatus to Report Expected Errors

LOG:Attempt to evaluate with a profile that does not have the 
correct transform;
EVAL:Reference=forward;
    SourcePixLayout=RGBInterLeaved;
    DestPixLayout=RGBInterLeaved; 	
    ImageIn=macbeth_1550.tif; 	
    ImageOut=None;
    Operation=Reverse; 	
    XStatus=4024; 
LOG:Attempt to evaluate an image with a content not available in 
the profile; 
EVAL:Reference=simulate;
    SourcePixLayout=RGBInterLeaved;
    DestPixLayout=RGBInterLeaved;
    ImageIn=macbeth_1550.tif;
    ImageOut=None;
    Operation=Image;
    Operation=Reverse; 	
    XStatus=4024;