[cairo] Subtractive API, part 0

[Christoph Lindemann]

I have combined my comments to several messages in this reply. Please
see below:

From: Chris Murphy ----------------------------------
> > 2) Can spot colors and similar be expressed in RGB with attached
color
> > profile?
> > I was thinking, that you could handle (in the code) all color in
cairo
> > with RGB (or whatever is used right now) and for the color handling
be
> > able to attach a color profile.
> > So the inner workings and API of cairo would not need to be changed,
but
> > would be backwards compatible.
> 
> The RGB color space would need a large enough color gamut in order to
> contain the spot colors.

Does not the gamut only depend on the color profile?

Maybe I was not clear enough, about what I meant, sorry.

Can you express spot colors in RGB >as computational data< with attached
color profile? The reason is, to find out if the current RGB type of API
is sufficient, or if you would really need to add new color API that can
take a different number of colorant values.

Can you map from a given spot color to RGB values with an attached color
profile, where the RGB values are whole-numbers (unsigned integers)?
Or do you need to be able to specify these RGB value using integer
(positive and negative)?
Or do you need these RGB values to be expessed as real numbers?

Or do you need the data format be something completely different, like 3
integers for RGB and 2 real for Hue and Saturation.

From: ecir hana ----------------------------------
> - Would I get the same results across different platform? (IIRC, why
> then Firefox developed their own CMS?)

Well, you might not get the same result on all platforms. Like you would
not get the same result from printer to printer, because they might use
different RIP and CMS.

I think it is more important that you get the same (or near) result on a
platform between cairo and non cairo applications.
Say, if you view an image in application ABCairo which uses Cairo, it
should view the same as in the application App.Net which uses GDI+.

I think it is reasonable, that the GDI surface would use Windows CMS
implementation, as this would be the same most other applications use on
Windows.

If it is important that >your< application is exactly the same across
platforms and surfaces, then you could hook/override the cairo CMS
handling - globally - to provide your own CMS functionality.

Also I do not think, that using only one CMS on all platforms would
positively give the best (same) result. As this CMS can not know all the
surface specifics.
Example, using LittleCMS might not be ideal on a "new cairo acme
printer" surface, as this surface would be able to do much better CMS on
its own because it knows about halftoning patterns used. (this example
might be far fetch, I don't know)

So I think every surface should provide its own CMS service/interface
(behind the back this could map back to one internal CMS), because the
surface has most knowledge about if and how CMS functionality should
work for that particular surface (for instance, the PDF surface would
just hand down the color profile data into the file)
Now cairo should also provide for overriding the CMS interfaces
globally, so an application could provide its own implementation.
Cairo should only implement a very rudimentary CMS, for fallback used
with surfaces that do not implement CMS interface, this could optionally
be made to link to AcmeCMS (or whatever cairo devs decide). This
fallback should also be implemented so you could override it.
Maybe you could just make the cairo cms interface override-able, and
then set an option on a surface object, if it should use surface cms or
cairo fallback. Or you could sat a global flag, which indicates all
surface should fallback to cairo CMS

This way you would get a very customizable solution. That would be able
to fit all use-cases.
-On embedded: do no overrides, and you get virtually no CMS but high
speed and low mem.
-In standard Application: do nothing, and you get "automatic" CMS for
current platform. GDI surface uses Windows CMS, X Windows surface uses
whatever you use on unix. When you render to PDF, you get PDF with
embedded profiles...
-In special Application (like print proffing): You override and
implement your own CMS. So you can take into account RIP, halftoning...
or make sure your application works exactly the same across platform.
-In firefox case: Override and implement special CMS, and you get same
result on all platforms, and high speed (as you can drop some CMS
functionality)


From: ecir hana ----------------------------------
> - What about pixel surfaces? Who would do the managment there? Would
> you need to convert an image surface to native surface, do the
> conversion and then back? You mention TinyCMS bellow, is this the case
> for it? Then, why to for all the surfaces - you would have to deal
> with platform specifics...?

Pixel surfaces would use standard cairo fallback CMS. If the application
developer uses pixel surfaces and cares about color correctness, he
would a) make sure all his source data (images, graphic commands) use
the same color profile, or b) hook in his own CMS implementation.

Other surfaces that might be using pixel surfaces internally, could hook
their own CMS ontho the pixel surfaces they create.

This actually might be a good reason to default link cairo fallback CMS
to an standard CMS implementation like LittleCMS or the current OS
platform implementation. Cairo should still provide a standard "do no
color correction" CMS for use when backwards compatibility with older
cairo is needed or for speed and memory reasons on embedded platforms.


From: ecir hana ----------------------------------
> - What about platform, which does not have CMS? Something like
> TinyCMS? The point is, if Cairo should reply on OS for color
> management and use some library if CMS is not available, why to use
> that library for everything and everytime?

If a platform does not provide CMS functionality, cario would fallback
to its standard implementation which could be LittleCMS or something
else.
You ask: Why not use the same CMS implementation for everything: please
see my comments above.