[Openicc] meta data in test chart

[edmund ronald]

I too see little reason for any part of Gutenprint to be involved
here, except as a consumer of settings files and profiles. Setting
format skeletons would be defined for each new printer model.

The idea is that anyone can if necessary tune any print setting,
create a complete recipe, and email it to any other user or upload to
a repository for re-use. For consumer use to be possible, the recipe
should have an associated "canned" ICC profile; In due course when
profiles are available for most media this ought to enable us to omit
most time-consuming color-tuning from Gutenprint, and replace it with
a filter that converts from whatever the system's naive user-space is
(sRGB?) to printer space. At the moment, Gutenprint offers manually
pre-tuned color presets for its naive users.


Edmund




On Fri, Jan 21, 2011 at 3:37 AM, Robert Krawitz <rlk at alum.mit.edu> wrote:
> 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.
>