[Openicc] ALL YOU NEED IS A PROFILE, THE MYTH. (WAS CC Profiles In X Specification and dispwin)

[Robert Krawitz]

   Date: Fri, 18 Jan 2008 12:53:49 +0000
   From: "Alastair M. Robinson" <blackfive at fakenhamweb.co.uk>

    > Oh, and by the way there is such a thing as XML which has been
    > created exactly for this purpose of creating portable
    > (parameter) files which are both machine readable and human
    > debuggable.

   Gutenprint already makes significant use of XML - both internally
   and externally.  Both the list of available printers and papersizes
   are stored as XML files in the filesystem, and the current
   papertype-specific colour adjustments are in XML format, even
   though they're inlined in the C code (escp2-paper.c et al).

Well, the curves are in XML format, at any rate.  The rest of it
isn't.

   The parsing overhead of XML should not be ignored though.  Parsing
   the existing XML files adds a good 15 seconds to every valgrind
   test I perform on PhotoPrint, for instance.

That's actually not where the overhead resides -- the problem is in
the construction of the initial sets of printer options, but suffice
it to say that that has nothing to do with XML parsing.  You'll be
glad to know that the mainline already has a fix for this (initialize
this stuff on demand).

That said, one central file containing everything for every
printer/paper/ink/what have you combination would be prohibitively
large.  That almost surely *would* take a very long time to load.

						For this reason, I'd
   rather see individual XML files containing a specific printer's
   tuning, parsed only when it's needed, rather than a single
   monolithic XML file containing everything.  Should make
   version-management easier too, if multiple people are going to be
   working on linearization.

Well, the issue is that we have tunings for papers, ink types
(e. g. photo black vs. matte black), and printers, and a lot of times
things get shared between printers (e. g. the same paper tunings get
used for many printers).  I'd rather not have to fully expand out the
definitions for every one of the 85 or so distinct printer models
(there are a lot more Epson printers than that, but a lot of them are
identical underneath) -- it's liable to make for a maintenance
nightmare if it's not done right.  For example, there are a lot of
printer models similar to the 870 in terms of inks, drop sizes,
papers, and all that, but which otherwise differ in minor ways (the
1270 is wide carriage, the 890 offers 2880x720 DPI, the 1280 is wide
carriage and 2880x720 DPI, something else offers roll feed, some other
variants do borderless in different ways...I counted about 8
variations on that particular theme).  Having to go back and find
every single one of those if we need to change something about the
tuning for one of them makes the maintainers lot not an 'appy one.

I don't want to do one hacked up XML job, only to find out that it
doesn't really help people and it makes our lives worse, and then have
to keep redoing it.

Alastair, do you have any thoughts about this?

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton