[Openicc] meta data in test chart

[Robert Krawitz]

On Fri, 21 Jan 2011 02:24:26 +0000, Alastair M. Robinson wrote:
> On 21/01/11 01:07, edmund ronald wrote:
>
>> I think we need to choose between XML and JSON. Robert will have final
>> say, I guess, but we might as well have it out there.
>
> I'm with Graeme in thinking XML is a horrible format to edit by hand
> (because the tags and the <> delimiters all have the same visual
> "weight" as the data within, so to my eyes it all just congeals into
> a mass on screen.)  However, despite my dislike of it, I think XML
> might be the better fit in this case.
>
> What needs to be able to parse the serialised options, and what can
> just treat it as a "blob"?
>
> * Gutenprint: Obviously needs to be able to both parse and write.
>
> * Oyranos, colord, etc.: Do they need to parse, or is a test for "equality" (for some yet-to-be-determined definition of "equality") sufficient?
>
> * ArgyllCMS: I would think profiling tools in general would need no awareness of the contents and would treat the data as a blob to be embedded in the final profile?
>
>> One argument in favor of JSON is that we can expect to write GUI's
>> to manipulate settings for the user so JSON is a good fit.
>
>  From my experience using the Gutenprint options system from within
>  PhotoPrint I'd say the options' limits and their interactions with
>  each other are *way* too complicated to be encoded within a
>  serialised options file, so a GUI tool to edit such a set of
>  options would probably need to be linked with libgutenprint.  Such
>  a tool (at least a Gutenprint-specific tool) would be far better
>  off deserialising an options file into a live stp_vars_t, editing
>  that, then serialising it again than attempting to parse a file
>  itself and implementing its own internal model with option
>  constraints.  Gutenprint already has an XML library, so I don't see
>  much sense in making Gutenprint use a different parsing library
>  just for option serialisation.

It's actually far from clear to me that Gutenprint (specifically,
libgutenprint) needs to be involved here at all, beyond maybe defining
a representation for non-scalar options.  But we already have a
representation for curves, which are currently the only composite
option type.

Before we talk about representation, I'd like to know what people
think Gutenprint needs to get involved with here.