XCPD Manual (Part 2)

XCPD Color Management Scheme

CM Abstraction Overview

The XCPD Color Management Layer is the intermediate abstraction between the dialog and the internal color management code.  It rests just below the XCPD, keeping the CM code hidden from the dialog programmer.  This layer contains two XCPD CM Modules, one that provides the processing of XCPD’s profile-selection functionality, and the other its PDF rendering capabilities.  The former is handled by the Oyranos APIs and the latter will primarily use Ghostscript.

In order to establish a bridge between the dialog interface and the internal CM code, the XCPD CM Layer contains the XCPD Color Management API, which will provide functions to allow the dialog programmer to send and receive color management information (without ever needing to know how the CM code is implemented internally).

XCPD Color Management Layer

The goal behind the XCPD Color Management Layer is to make color management in the printing dialog simple.  That is, the printer dialog programmer shouldn’t have to know how color management works – only that by following the workflow model, and invoking the appropriate function into the XCPD CM Layer will the dialog programmer know that color management will simply happen.  Strings are attached in the dialog, but the color management “puppeteer” is always invisible.

Outside libraries (Oyranos/Ghostscript) are linked here, although more specifically to the XCPD CM Modules.

XCPD CM Modules

The XCPD CM Layer contains two color management modules, which are considered to be the processing components of the layer:

-The “Profile Selection” module is essentially an extension of the Oyranos API, providing support for XCPD’s profile-selector.  It uses the Oyranos Core to look up, parse, and rank ICC profiles, as well as the Oyranos/CUPS module to obtain printer-related color information from the PPD.

-The “PDF Renderer” module uses the Ghostscript interpreter to handle profiles inside a PDF file.  Its duties include checking for the existence of the OutputIntent in the PDF and tagging a DeviceXXX space with the appropriate ICC profile.

Each module is stored as a separate source file.  The modules are tasked to perform their duties as invoked by the dialog programmer through the XCPD Color Management API.

XCPD Color Management API*

This is the interface that binds both the dialog and the XCPD CM Layer together.  The API’s goal is to not concern the dialog programmer with the details of color management, but rather its workflow as it relates to printing.

Each API function will call an appropriate module from within the CM layer:  A call to, say, “xcpdCM_getCalibratedProfile()” will invoke the Profile Selection module internally and return a profile to the dialog.  Calling a function such as “xcpdCM_checkOutputintent()” will invoke code in the PDF Renderer module and return an int (true or false).

All of the API code is contained in its own source file, and is to be included in the dialog with the statement #include “xcpdcm.h”.

Functions in the XCPD module use the following naming format:

xcpdCM_functionName()

(Where “xcpdCM” is the prefix followed by an underscore, and the name of the function in lower camel case.)

An xcpdCM structure will be used to pass color-related information from the dialog, and passed to the XCPD Color Management Layer through one of the xcpdCM functions. . .

*More details regarding the xcpdCM structure and the entire API will be available in Part 3.  All updates to this draft will be made on the ColourWiki page.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s