[CREATE] colour lists; in Oyranos?

[Craig Bradney]

> Yes, I thought of a small lib independently usable of Oyranos. Something
> like liboyranos_colourlists.so. A Project can use it with Oyranos or take
> the code over for portability. Code to read xml is needed as well.

Sounds ok.

> > a) Many people don't have profiles
> > b) Many don't know how to create one
>
> The user interface would be in the applications, using mostly the current
> code. Just writing things out to a profile instead of a text file.
> As well, no one creates hand written colour lists (as far as I heard).

Create a profile....

> > c) Many don't have a need for one (no need for colour management either)
>
> Do You mean they dont need colour palettes? So they dont need the spec
> eighter?

I mean many people done need profiles, ie, they "just want to work" with what 
they get from a default install and thats it. Some examples: Scribus for PDFs 
for the web or presentations, Inkscape or Gimp for web graphics. The fact 
that profiling can help even in these situation, is for many people, 
irrelevant.

> > d) Many will have equipment not "worth" profiling (older/cheap LCDs,
> > older CRTs etc, or simply those without manufacturers' drivers or
> > profiles.)
>
> How does this belong to colour lists? They are independent from a
> for instance device profile.

Profiles, as above. Sorry for confusing the issue. I meant relying on colour 
lists embedded in ICC profiles brings a lot of extra baggage with them.

> > I think the best way is still an XML based file, but as profiling is
> > important to many, if the colour sets are defined with a certain target
> > in mind then they could reference an ICC profile, if that makes sense.
> > When both are used in combination, you get the same effect as above, I
> > think. Perhaps the possibility to import/export from a profile into an
> > XML format would also be of use. This would also lead to binary
> > conversion from XML, and hence the ability to fit with the industry that
> > wants such formats.
>
> What does a text based format provide other than the text form? Dont we
> end up in different formats for the same thing?

Text based vs text form? Don't follow.

regards
Craig