[CREATE] Swatches: Proposition J

[MenTaLguY]

On Mon, 2008-06-23 at 19:59 +0200, Cyrille Berger wrote:
> Ok, now that I have cooled down a little bit (I hope I haven't offend anyone, 
> but please, don't move spec around without a discution), I can be a little 
> bit rational, and make a few comments.

I think your posted response was perfectly reasonable.

> The main interest is that it allows to define a color in a non-RGB 
> colorspace, like you allow too, but your proposal doesn't allow a fallback 
> for application that can only read and use RGB, that would mean they simply 
> can't use the color.

The lack of an sRGB fallback built-in is a major problem with my
approach.  My thinking at the time I wrote the original spec was that
"fallback" color specifications could be provided as an extension, but I
did not pursue that further once I realized that the CREATE swatches
work had proceeded and I needed to synchronize with it rather than
continue off on my own.

However, if a color is simultaneously specified in several different
color spaces, those specifications are going to conflict since the
conversion between color spaces is dependent on factors like rendering
intent which are not specified at all in the current form of Proposition
H.  There does need to be a way to specify which of the several color
specifications is (are?) authoritative and which are derived.  In the
case of my format, the authoritative specification would be the <color>
element, and any derived specifications would be children of it.

I think the simplest way to address this in the adopted CREATE swatch
format, would be to designate the first specification for a swatch as
authoritative, and the remainder as derived.

> Then there is "color" vs "rgb" for the tag name. Well, originally, we choosed 
> the second form for the validation purpose, after what Liam said about 
> validation in the OpenRaster thread last week, it seems it doesn't matter 
> much anymore. On the other hand, for me it would suck to have to go through 
> the code in krita to change that (and I don't know if there are other who 
> have allready implemented the draft and would be unhappy about the change).

I'm not really concerned with tag or attribute names: they are largely
cosmetic, and changing them at this point would be needless trouble for
you and others.

> The only thing your proposal have, and that the current draft doesn't have is 
> spot color, but it's not because I am against, or anyone else, it's just that 
> I don't know what would be the requirements for defining spot colors, so I 
> prefer to leave that to other.

Spot colors were actually the motivating reason for me to design the
format.  But having somewhat caught up with the discussion I am not as
satisfied with my solution as I had been.

Setting spot colors aside for the moment, because I need to think about
them more, there are actually several non-cosmetic differences that I'm
concerned with:

 1. The ability to embed an ICC profile in the swatch file itself (as
base-64 encoded data), rather than requiring the user to distribute it
as an additional "sidecar" file.  Unless implementations provide a
convenient way to bundle the profile with the swatches, I do not think
the color management features of the swatch format will get used.

 2. Allowance in the schema for including annotations using attributes
and elements from foreign namespaces, at least in specific places (my
proposal is perhaps overly generous in this regard).  If the schema
permitted extensions, it would be possible to include foreign
annotations in defined places, knowing that all conformant
implementations which did not understand them would be guaranteed to
safely ignore them.  This would reduce the need for the main
specification to support features like spot colors.

 3. By requiring dependencies (e.g. color spaces) to appear before their
dependents (e.g. colors), I eliminated the need for forward references,
which would otherwise have increased implementation complexity and
precluded pure streaming approaches to parsing.  In my experience,
forward references are rarely implemented properly by first-generation
"third party" implementations of a format.  In the case of SVG, it was
something we had to spend quite a bit of time straightening out when we
inherited the Sodipodi codebase, and I believe forward references have
been an issue for librsvg in the past as well.  The added complexity of
forward references is justified for SVG, but I am less sure that that is
true of swatch files.

 4. If we specify a color in a color space with a specific ICC profile,
we also need to know what rendering intent to use when converting the
color to other color profiles/models.  In many cases this is going to
depend on the "use" of the color.  Relative colorimetric is probably the
most reasonable default, but for certain specific colors other rendering
intents make more sense (e.g. absolute colorimetric for spot colors in
some color matching system), and I think it needs to be possible to
indicate this in the swatch file.

I do not think any of these for adjustments would require significant
changes to existing parsers.  Thoughts?

-mental
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/create/attachments/20080623/9aba0d3e/attachment.pgp