Re: [Gimp-print-devel] printrc file format

[Roger L. <ro...@wh...>]

Robert L Krawitz <rl...@al...> writes:

>    From: Roger Leigh <ro...@wh...>
>    Date: 26 Jan 2003 19:24:41 +0000
> 
>    Robert L Krawitz <rl...@al...> writes:
> 
>    > The current printrc file format isn't powerful enough to take
>    > advantage of the new features, such as curves, raw data, and all
>    > that.  I think it's time we came up with a new format that's more
>    > extensible.  Perhaps we can use some of the XML stuff for that?
> 
>    This is possible: I was looking at converting the curve read and print
>    functions to reading and writing XML.  This has the disadvantage of
>    being less space-efficient, but can then be included in XML data
>    files.
> 
>    Would
> 
>    <curve type="curve_type" wrap="wrap_mode" gamma="double"
>      lower_bound="double" upper_bound="double">
>      <curve_point value="double"/>
>      [...]
>      <curve_point value="double"/>
>    </curve>
> 
>    be OK?  I've missed out the point count, because it's implied by the
>    number of curve points (but what about the ghost point)??
> 
> This is likely to be a bit too big; the "curves" that are the dither
> matrices are about 64K points.  The curve representation that we're
> currently using isn't a problem, although perhaps we can come up with
> a shorter XML representation.  I'm more concerned about the printrc as
> a whole.

I've now modified it.  It's now more compact than the plain ASCII
format:

roger@whinlatter:~/gimp-print/xmldef$ ls -l 1x1.*
-rw-r--r--    1 roger    leigh      462408 Jan 28 15:12 1x1.mat
-rw-r--r--    1 roger    leigh      409427 Jan 28 17:08 matrix-1x1.xml

The new format is like this:

<?xml version="1.0" encoding="UTF-8"?>

<gimp-print xmlns="http://gimp-print.sourceforge.net/xsd/gp.xsd-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://gimp-print.sourceforge.net/xsd/gp.xsd-1.0 gimpprint.xsd">
  <curve type="Linear" wrap="Nowrap" count="66051" gamma="0" lower_bound="0" upper_bound="65535">
    257 257 0 59688 17885 33107 58234 12934 35793 44835 5911 41622
    17122 47448 37402 13125 45769 3041 64479 7193 26025 48883 23186
    8596 56304 31276 62070 7419 58111 28763 52231 25607 36689 7878

[...]

    23336 50938 8755 34843 52152 11139 36390 23208 49729 16233 40306
    65203 26388 51929 32157 7154 46084 14871
  </curve>
</gimp-print>

I found that the content within a pair of tags can be a "list" of
whitespace-separated values.  The schema for this is:

  <xsd:simpleType name="curvelist">
    <xsd:list itemType="double"/>
  </xsd:simpleType>

  <xsd:element name="curve" type="curvelist">
    <xsd:annotation>
      <xsd:documentation>
	The "curve" class stores a complete stp_curve_t curve
	representation.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:attributeGroup>
      <xsd:attribute name="type" use="required">
	<xsd:simpleType>
	  <xsd:restriction type="normalizedString">
	    <xsd:enumeration value="Linear"/>
	    <xsd:enumeration value="Spline"/>
	  </xsd:restriction>
	</xsd:simpleType>
      </xsd:attribute>
      <xsd:attribute name="wrap" use="required">
	<xsd:simpleType>
	  <xsd:restriction type="normalizedString">
	    <xsd:enumeration value="Nowrap"/>
	    <xsd:enumeration value="Wrap"/>
	  </xsd:restriction>
	</xsd:simpleType>
      </xsd:attribute>
      <xsd:attribute name="count" type="positiveInteger" use="required"/>
      <xsd:attribute name="gamma" type="xsd:float" use="required"/>
      <xsd:attribute name="lower_bound" type="xsd:float" use="required"/>
      <xsd:attribute name="upper_bound" type="xsd:float" use="required"/>
    </xsd:attributeGroup>
  </xsd:element>

Is this OK?

>    The XML code currently only does reading, but changing it to write
>    data shouldn't be too hard (this might have some security
>    implications, though, if a print job could request data to be saved
>    when run by a priveliged user).
> 
> If the printrc stays in the UI library, this shouldn't be an issue;
> certainly I would not envision the core library saving anything out
> except under explicit higher level control.
> 
>    Alternatively, if the Print plugin also uses XML as the config file
>    format, it could probably embed the stp_vars_t state within its own
>    data.
> 
> That sounds like what I had in mind.

I'll get the curve stuff done, and then look at the printrc.

Looking back at your previous suggestion to have functions to directly
read/write XML data, it will probably be worth having functions to
turn a curve "xmlNode" to and from an stp_curve_t, and read/write this
to disk.  By having the reading/writing and conversion separate, you
could pass it selected bits of an XML tree (for embedding in files
outside the control of libgimpprint), or have it just use a simple
"one thing per file" method of access.


-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers