As stated on the Calligra/Pigment page, all KOffice applications will do Calligra/Color management. So the question is how are we going to actually pull this off.

Introduction

For color management to work we must store extra information with a color, things like the color profile used for example. This means we can't just use QColor. Which in term means we can't paint our internal data structures to a QPainter as is. There are two strategies to solve this, one is to extend QPainter or one of its implementations, and the other is to convert from our internal colors to a QColor at painting time.

I'll go into the last strategy more as it is simpler to maintain and implement with little to no downsides. While the enhancing of QPainter does not even seem possible. Though if it were possible it probably still is not the best solution.

The strategy

In all data objects we store a color, we will store a color with its profile; in the form of a KoColor instead. This will have the effect that internally all data objects will have the most perfect color registration.

All ways for a user to input color, like a color selector, will generate only a KoColor. Which will be used on the data objects. We have 2 output methods. 1) to screen, 2) to printer. To output to screen we always have to convert to rgb8 (aka QColor) as our display device takes nothing else. The suggestion here is to use a normal QPainter and generate a QColor for painting from the internal KoColor. The only conceptual loss here is that composition (placing semi transparent objects on top of each other) is done in rgb8 instead of a better colorspace. As this is for displaying purposes only that is acceptable. Do note that Krita does its own composition so this downside does not apply there.

The second output method is 'to printer'. KDE wide we choose to use PDF output for that, in cooperation with printer makers which are switching from various formats to allow you to sent a PDF to the printer directly. Naturally apps like ghostscript can still be used to convert to printer-specific languages in the mean time. To print to printer we can only use 3 colorspaces as PDF does not allow more; rgb, cmyk and lab. Thus this requires us to convert this. At this point in time (March 2007) the Qt PDF printer does not allow us to print other then rgb8. So any discussion on how to do this best is moot until we have a solution that is capable of reusing the color management features while printing.

Data Structures

To paint any sort of structure QPainter uses two categories of objects. Objects that show area / surfaces and objects that show content. The objects that show area/surfaces are things like QRect, QPainterPath etc. These are not used for color management and thus can be reused for our purposes without alteration. The second category of objects that QPainter uses are QColor based. The exhaustive list is;

QColor
QBrush
QGradient
QPixmap / QImage

These 4 classes are used by QPainter and thus we should be able to create them from our color managed data at the time we paint. We already have a KoColor which can generate a QColor. We additionally need a KoBrush, KoGradient and a way to store images.

KoBrush

A QBrush technically is nothing but a container for painting strategy (fill). Which is either a color, a gradient, a picture or a pattern (including no fill). I suggest to create a new class KoBrush. It holds a KoColor, and optionally a KoGradient and QPixmap. It should have a QBrush toQBrush() const; method.

KoGradient

QGradient is an abstract baseclass with 3 known implementations; QConicalGradient, QLinearGradient, and QRadialGradient. Most importantly; none of those can be safely inherited from to enrich them with data. [more]

Images

The goal of enriching QPixmap instances with color managed data as that is used in KOffice is limited to reusing image data that is created by Krita. For all other cases we can simply reuse the QPixmap version. [more]