[CREATE] Swatches: Proposition J
cberger at cberger.net
Mon Jun 23 10:59:22 PDT 2008
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.
The key difference between your proposition and the draft is
<color name="Blue" cs="my_printer" c="1 0.25 0 0" />
<rgb space="prof01" r="1" g="0.25" b="0"/>
I note a second difference, the draft allows to set the value in a different
color space for the same colors, while I don't see it as possible in your
proposal. 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.
Then there is ' c="1 0.25 0 0" ' against ' r="1" g="0.25" b="0" ' . I must
say I prefer the second form, I agree that spliting a string containing
numbers separated from spaces is easy, but why do the job twice, once in the
XML parser and a second time while decoding the color ? Besides, with c ="1
0.25 0 0" which is red ? the first one, or the third one ? While with r="1" g
="0.25" b ="1", you don't ask the question, you just know.
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).
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.
More information about the CREATE