Re: What I'm up to

Robert L Krawitz <rlk@xxxxxxxxxxxx> writes:

> Now, what I'm up to: I'm looking at printers.xml with an eye toward
> the following:
>
> What I ultimately expect the file to look like is something like this:
>
>     <family name="escp2">
>       <driver name="escp2-580" model="42">
>         <parameter type="float" name="MagentaGamma" value="0.95"/>
>         <parameter type="float" name="YellowGamma" value="0.9"/>
>         <parameter type="float" name="Gamma" value="0.731"/>
>         <parameter type="float" name="Density" value="1.0"/>
>       </driver>
>     </family>

I would prefer

          <parameter type="float" name="Gamma">0.731</parameter>

Although it's slightly longer, it allows you to do things like:

          <parameter type="curve" name="GammaCurve">
            <curve wrap="nowrap" type="spline" gamma="0" piecewise="false">
              <sequence count="11" lower-bound="0" upper-bound="1">
                0 0.11 0.24 0.34 0.43 0.58 0.69 0.75 0.95 0.96
              </sequence>
            </curve>
          </parameter>

i.e. you can embed arbitrary stuff that you couldn't do with the
element attributes.  Since we know the datatype, we can call the
appropriate routines to deserialise into a suitable type.

WRT the driver model number attribute, I would prefer (in the long
term) if this could be removed, and the per-driver data in
print-escp2-data could be moved here (is this the intent?).  This
would require separate elements to specify the inksets, drop sizes
etc., and should hopefully be usable by all family drivers (if the
escp2_ types could be made more generic).

>     <printers>
>       <printer name="EPSON Stylus Color 480" driver="escp2-480" 
> manufacturer="Epson"/>
>       <printer name="EPSON Stylus C20SX" driver="escp2-480" 
> manufacturer="Epson"/>
>       ...
>     </printers>
>
> I suppose we could ultimately allow overriding of parameters in the
> printer declaration, but my intent at this point is to not allow that.

OK.  That seems just fine (and allowing overriding here may not make a
lot of sense, since if you need to override, it's effectively a
different driver).  It might be simpler (to understand) if drivers can
inherit their properties from other drivers, and override what's
different, and leave the printer out of it.

> This can all be done without any API change at all, other than the
> fact that there will no longer be a 1-1 mapping between printers and
> drivers, so stp_get_printer_by_driver would have to return something
> arbitrary, like perhaps the first printer encountered that uses a
> particular driver.  However, it would be useful to allow applications
> to get drivers as well as printers, so that e. g. test programs don't
> have to keep a list of what drivers they've already seen.

I'm not sure stp_get_printer_by_driver() is particularly useful
now--what would a normal application need it for?  I guess the test
program case is special, but surely they can just maintain a list of
previously-seen drivers?

> We could choose to preserve compatibility by keeping all of the
> stp_printer calls (which would essentially be shorthand) or not.

When considering backward compatibility, what other applications
(outside our source tree) are making use of libgimpprint directly?  I
only know of CinePaint.  If there's noone using them, we could remove
them.

> What do people think about this?

It sounds good.  One other thought:

Currently, printers.xml is parsed once, but using
stp_register_xml_preload().  This prevents installation of arbitrary
third-party family drivers, since it would require manual editing of
the file.  Perhaps it would be better to split the file into one file
per family, which would be parsed by the family driver during its
initialisation.  Even better (but less efficient) would be to have one
directory per driver
(e.g. /usr/local/share/gimp-print/VERSION/xml/driver/pcl/).  This
would allow others to extend the driver without editing the installed
files.


-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click