[Openicc] meta data in test chart

[Ann L McCarthy]

Please be aware that SampleICC already includes an XML <=> ICC format 
capability.
Any tags in an ICC profile can be edited in an XML editor using that 
capability for pre- and post- conversion.
This obtains the XML text editing experience and at the same time retains 
the efficient storage format of the ICC profile.

Best regards,
Ann McCarthy
Imaging Systems R&D
Lexmark International, Inc.






"Alastair M. Robinson" <blackfive at fakenhamweb.co.uk> 
Sent by: openicc-bounces+almccart=lexmark.com at lists.freedesktop.org
01/20/2011 09:24 PM

To
edmund ronald <edmundronald at gmail.com>
cc
OpenICC Liste <openicc at lists.freedesktop.org>
Subject
Re: [Openicc] meta data in test chart






Hi,

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.

All the best
--
Alastair M. Robinson
_______________________________________________
openicc mailing list
openicc at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openicc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110121/cc23365e/attachment.htm>