On Fri, 27 Feb 2004, Peter Linnell wrote:

Hi all,

To clarify: IRC meet at #scribus on freenode.net 07:00 CET Sat 28 Jan. = 1 AM EST or 10 PM PST. Fri. PM

Please review the notes at: http://www.inkscape.org/cgi-bin/wiki.pl?ScribusInteroperability

Thanks and look forward to this.

Peter

Thanks for setting this up Peter, I'm looking forward to meeting the Scribus folks and hope it'll be a good meeting.

Bryce

Craig Bradney wrote:

Hi All,

Attached is the SVG colour set we discussed today. Its only in the X11 rgb.txt format but it is complete and (hopefully 100%) correct. When/if we come up with an XML format it can be converted.

At the moment that color set is in Inkscape under inkscape/src/svg/svg-color.cpp

Maybe someone should verify it's the same.

Oh, and I took a peek at the CxF paper, and though a little of it can be overkill, it's fairly optional and does contain a lot of information that we could need.

Hi Jon, and all

...

Attached is the SVG colour set we discussed today. Its only in the X11 rgb.txt format but it is complete and (hopefully 100%) correct. When/if we come up with an XML format it can be converted.

At the moment that color set is in Inkscape under inkscape/src/svg/svg-color.cpp

Maybe someone should verify it's the same.

Oh, and I took a peek at the CxF paper, and though a little of it can be overkill, it's fairly optional and does contain a lot of information that we could need.

Looking at just the CxF sample I think its pretty huge for what in the end turns out to be a basic need which isnt too big in the end.

Peter and I discussed it later today a little further. In the end we came to the conclusion that there is no real need to store anything other that pure colours, whether that be in RGB or CMYK (or perhaps HSV?). The idea is to share colours, not the use of them. That is, so we can share a colour set so when a file is loaded, the same colour set is accessible in Inkscape and Scribus etc.

The named SVG colour chart stores the colours in RGB values only - it does not have/need anymore information.

For our purposes, especially in Scribus, users WILL want to be able to define CMYK colour sets. If we don't, they WILL ask how to do it so in this case its better to get it done correctly from stage 1.

I grabbed some info from: http://marvin.mrtoads.com/richblack_vs_plainblack.html

The example is black: In RGB, Black is RGB:0,0,0 In the printing world you have other blacks such as: Rich Black: CMYK(%):63,52,51,100 Cool Black: CMYK(%):60,0,0,100 Warm Black: CMYK(%):0,60,30,100

I pretty sure we can handle those ok in Scribus.

So onto the XML. Firstly. I'll say I'm no XML expert so what I'm typing is just a rough guesstimate of some markup, given the above,

<colorset name="reds"> <color type="rgb" name="my-red" red="f" blue="0" Green="0" /> <color type="rgb" name="my-red" red="ff" blue="00" green="00" /> <color type="rgb" name="my-red" red="100%" blue="0%" green="0%" /> <color type="cmyk" name="my-red" cyan="0" magenta="255" yellow="255" black="0" /> <color type="cmyk" name="my-red" cyan="0%" magenta="100%" yellow="100%" black="0%" /> </colorset>

They are the kind of lines I see possible. Someone with real XML knowledge can convert it to something useful. :)

I have used the RGB definitions based on the SVG colour specifications and also given them for CMYK versions, hence the f,ff,100% equivalents.

Going back to what I said above, this is about sharing NAMED colours, not really their uses. Its about giving the Inkscape users the ability to choose "Red" instead of having to use sliders or wheels or entry fields etc, and to make sure that "Red" can come across to Scribus ok, and vice versa. (Note: "Red" in one colour set might be RGB:0,0,0 if someone wants to call it that - kind of like redefining a style in CSS. Scribus supports this kind of "Colour Style" inherently with named colours. Changing the 0,0,0 to something else changes the elements with that named colour.)

So, do we need transparency/opacity values? Maybe... but are we going to give the option to a user to use a predefined RGBA colour or just give them an RGB colour and they set the opacity/transparency etc for that document element?

Surely the opacity etc is a choice for the document, not for the colour set and therefore not in the colour set but held in the document elements paired with the actual colour like they are now. If others disagree, its easy to add an attribute or two.

hmm.. thats where I'm at with it all, and I'll leave it there for comment.

regards Craig

On Sun, 2004-02-29 at 00:38, MenTaLguY wrote:

On Sat, 2004-02-28 at 17:56, Craig Bradney wrote:

...

So onto the XML. Firstly. I'll say I'm no XML expert so what I'm typing is just a rough guesstimate of some markup, given the above,

<colorset name="reds"> <color type="rgb" name="my-red" red="f" blue="0" Green="0" /> <color type="rgb" name="my-red" red="ff" blue="00" green="00" /> <color type="rgb" name="my-red" red="100%" blue="0%" green="0%" /> <color type="cmyk" name="my-red" cyan="0" magenta="255" yellow="255" black="0" /> <color type="cmyk" name="my-red" cyan="0%" magenta="100%" yellow="100%" black="0%" /> </colorset>

They are the kind of lines I see possible. Someone with real XML knowledge can convert it to something useful. :)

The basic idea looks sound. I might suggest something like this:

<colorset name="Reds" xmlns="http://www.scribus.org/colorset" xmlns:rgb="http://www.scribus.org/colorspace/RGB" xmlns:cymk="http://www.scribus.org/colorspace/CYMK" xmlns:panstone="http://www.example.com/panstone">

<color name="My Red"> <rgb:build red="100%" green="0%" blue="0%" /> </color> <color name="Another (Dark) Red"> <cymk:build cyan="0%" yellow="50%" magenta="50%" black="50%" /> </color> <color name="Panstone Green 23"> <panstone:color name="Green 23"/> <cymk:build cyan="23%" yellow="28%" magenta="2%" black="2%" /> </color> </colorset>

This is similar to the approach that RDF-XML uses, and permits the addition of new colorspaces without impacting the basic schema for colorsets.

The last example also illustrates specifying a color using different colorspaces in decreasing order of preference, which might be useful to supply an approximation for software that doesn't understand the preferred colorspace (in this case, the hypothetical "Panstone" system).

Actually, it might even be worth asking whether just using RDF-XML for this would be worthwhile.

All very interesting and I can immediately see the benefits. If there's a format that can handle what we need to achieve then we should use it.

The major issue I see above is there is a certain degree of complication over the basic format my monkeys and typewriters spat out. It does need to be a format editable by users, although they can already edit the existing colour sets in Scribus but cannot yet save them as a new set. Some would want to edit them in the XML file itself. Some really love the idea of scripting and doing conversions of doc formats to Scribus format etc. As long as its a defined XML+DTD format they would be happy I guess.

Is there a way to allow for various values (f,ff,100%,255), or is this just in the application that reads the file?

regards Craig

On Sat, 2004-02-28 at 21:09, Jon A. Cruz wrote:

Craig Bradney wrote:

...

Looking at just the CxF sample I think its pretty huge for what in the end turns out to be a basic need which isnt too big in the end.

Actually, there's a lot hiding in there that you really do need, and a lot that can just be ignored.

I'll take a pass later on and see what I can digest.

...

Peter and I discussed it later today a little further. In the end we came to the conclusion that there is no real need to store anything other that pure colours

True.

However the big "gotcha" is 'what is a color?'

...

whether that be in RGB or CMYK (or perhaps HSV?). The idea is to share colours, not the use of them. That is, so we can share a colour set so when a file is loaded, the same colour set is accessible in Inkscape and Scribus etc.

Exactly.

And that's where at the very least we're going to need some 'colorspace' to go along with numeric values.

RGB in SVG is pretty simple since it uses sRGB by definition. That is, you have numerical components and an explicit colorspace that those are in. Therefore we have the ability (in theory) of having the same "color".

CMYK, on the other hand, is a horrrrrrrrrrible problem. In and of itself, there is no "CMYK colorspace".

Correct and while there are a few "generic" CMYK color spaces, in reality a CMYK colorspace is almost always tied to a device.

...

The named SVG colour chart stores the colours in RGB values only - it does not have/need anymore information.

Actually, it does need more information. The specification of the colorspace those numbers are in.

And SVG has that.

http://www.w3.org/TR/SVG/color.html

...

12.1 Introduction All SVG colors are specified in the sRGB color space (see [SRGB] http://www.iec.ch/nr1899.htm)...

This a good thing to add to the Wiki.. all these links and specs.

...

For our purposes, especially in Scribus, users WILL want to be able to define CMYK colour sets. If we don't, they WILL ask how to do it so in this case its better to get it done correctly from stage 1.

Ahhh... good pinpointing of needs.

So... a CMYK colorset would also need to specify which CMYK colorspace it is. Bascially one per device. :-)

Good news is that LittleCMS probably has all that is needed for the workflow. The color palette format would just need to include which colorspace it is such that LittleCMS would be able to go in and out of RGB properly.

Exactly. One other wrinkle is rendering intents, which is not easy sometimes for end users to grok.. I mention this just as a caution for UI purposes.

Cheers, Peter