[Gnome-print] Printer & model description files

[Lauris Kaplinski <lauris ximian com>]

Hello Chema et al!

I have been playing with xml model & printer definitions. They are still
barebones in comparison with gpa original ones, but I'd think we can add
required features quite easily back now.

Model definition file:

Header:

<?xml version="1.0"?>
<Model Id="STYLUS-COLOR-740">
  <Name>Stylus Color 740</Name>
  <Vendor>EPSON</Vendor>
  <Version>0.0.1</Version>

Well, one may add as much data as needed here. The only important change
is, that vendor is referenced by id, not name (name should be 
translatable - I do not know, whether there will be vendors, whose
names will be translated, but I'd change it for consistency with other
nodes).

Options:

<Options>
  <Option Id="Engine">
    <Option Id="Backend" Type="List" Default="omni">
      <Item Id="omni">
        <Name>OMNi</Name>
        <Key Id="Driver" Value="OMNi">
          <Key Id="Module" Value="libgnomeprint-omni2.so">
          <Key Id="OmniModule"
Value="libEpson_Stylus_Color_740.so"/>
          </Key>
        </Key>
      </Item>
      <Item Id="GS">
        <Name>GhostScript</Name>
        <Key Id="Driver" Value="gnome-print-ps"/>
      </Item>
    </Option>
  </Option>
...

I have divided option nodes into 3 main categories - Option, Item and 
Key. This is arbitrary, as currently these are implemented as single
object type, i.e. it could as well be <Option Type="Key">, but I think
it makes things a bit more readable.

<Option> - is part of tree, that either has itself changeable value,
or has such children.

<Item> - is child of list option. If constructing settings, parent
list option and item child are merged into single node. In example
above, we will have Settings:
<Key Id="Engine">
  <Key Id="Backend" Value="omni"/>
</Key>
I.e. Option list "Backend" and item "omni" are merged into single
settings key. I reused node name "Key" for settings - it has some sense 
(read ahead).

<Key> is part of tree, that has no changeable values. So it can be
omitted from settings xml file, and read asis from option tree, if
needed. You can specify useful meta info via keys, like in above
example gnome-print and OMNi module names, needed for driver.

Most other things are either uncertain, or obvious. Possible Option
types are:

List - has children type Item
String - editable string (like output filename)
Number - just that, has additional facultative properties:
  Min, Max, Step.
Boolean - would make sense to have separate, so yes, no, true, false, 1,
  0 can be parsed more easily
Include - include from other file, has arbitrary number of children
  Value? - Selects path "OptionA.OptionB" from other file - so we
  can select resolutions selectively from master resolution file
  etc.
  Should also have "Condition", like for selecting papers with
  width <= somevalue.
  Should have merged with data present, so printer may add
  additional options, like "MicroWeave" to resolutions

Now, I do not need much more information at first. Such things like
control types (optionmenu, dropdown), differentiating between
integers and reals etc. are probably unnecessary, as control widgets
have to know the semantics of options anyways. But if you think they
are useful (like reading data from PPD), they may be kept there -
the tree structure is loose, so unknown keys are simply ignored.

Much more important is the final option tree skeleton. My current idea
is something like:

Engine
  Backend (basically gnome-print driver module)
    - various backend-specific keys

Output
  Media
    PhysicalSize - list of paper names (should be included)
      - has child keys Width and Height
    PhysicalOrientation - list of (0, 90, 180, 270). GUI will work out,
      how to present it to user (portrait, landscape...)
  Resolution - list of resolution names (should be included)
    - has child key DPI
      - has child keys DPIX & DPIY

Transport
  Backend (basically spooling system to use, like file, lpr...)
    - various backend-specific keys

Additional keys (my suggestions):
Output.Media.MediaType - paper type (glossy, ...)
Output.Imaging.Mode - color, bw...
Output.Imaging.Density - well, that may have children...
Output.Imaging.ColorSpace - colorspace if Mode == color, color
  correction should be in subtree for given colorspace
Engine.Backend.PSLevel - PS level, if Backend == PostScript? or backend
  is GhostScript? I am not sure, b-e should be PS, gs some subtype
Device.InstalledMemory - printer memory
Device.MediaSource - trays, ...

I have thought, whether to add "LogicalSize" to Media. I.e. application
  can set different logical page size, and there will be option, whether
  you want to scale, tile or crop result

I'd like to use '.' as separator, mainly because it makes the access
similar to ECMAScript/JavaScript. Mybe one day the configuration data
is stored in DOM and we can use JavaScript to create dialogs ;-)

Well, constraints.
I have not touched these, but I think gpa structure does make sense.
One super-cool but probably too complex to implement, would be to
specify constraints as ECMAScript/JavaScript expressions (to be verified
whenever system tries to set some setting value). Not that it
is absolutely needed, but it would remove the necessity to implement
Yet Another Control Language - as I understood that PPD contraints
could be quite complex.

Printer:

Header:

<?xml version="1.0"?>
<Printer Id="STYLUS-COLOR-740-000989526338006212000000">
  <Name>Stylus Color 740</Name>
  <Model>STYLUS-COLOR-740</Model>

That's all. Again we can add additional information.
Ah, forgot. For gp, I modified naming schemas, so model files are not
fixed length, and printer names are composed, as:
MODELNAME-XYZSOMEIDVALUE.printer
So they are easily locatable by hand.

Settings:

  <Settings Id="SETTINGS-000989526338006212000001">
    <Name>Default</Name>
    <Key Id="Engine">
      <Key Id="Backend" Value="omni"/>
    </Key>
    <Key Id="Output">
      <Key Id="Media">
        <Key Id="PhysicalSize" Value="A4"/>
        </Key>
      <Key Id="Resolution" Value="360x360"/>
    </Key>
    <Key Id="Transport">
      <Key Id="Backend" Value="file">
        <Key Id="FileName" Value="output.omni"/>
      </Key>
    </Key>
  </Settings>

Here are only part of option trees, that may change. Everything else is
read from options anyways.
Well, specifying keys as xml nodes is not necessary. Instead we could
use approcah similar to original gpa. I do not know, which would make
more sense. As I implemented settings as tree of nodes too, writing
xml was more straightforward.

Namespacing.
I do not think adding namespace to each node does make sense. AFAIK xml
spec allows you to add single namespace indicator to header, and all
node inherit it, unless specified otherwise.

Translation:
Probably will be something like:
<Name>
  <Value Language="ee">Hää ja kiire printer</Value>
  Default Name Here
</Name>
Or we can put default value into its own node (I have to check, what
XML says about such constructs).

About PPD imports:
We have to fix quite big set of configuration keys. If there are
unknown ones, these may go into certain spot, like
Device.Other
Together with GUI info etc. So one will be able to construct
advanced printer setup dialog, which allows changing these values -
but most certainly these would only clutter basic dialogs.

Well, again my idea:
There canbe enormous number of configuration keys. Certain set of
these are known by gnome-print dialogs. If there is more (and these
are important), printer should specify its own configuration
widgetry, possibly by providing known key, like:
GUI.Module

So, comments?

Best wishes,
Lauris Kaplinski




_______________________________________________
Gnome-print maillist  -  Gnome-print@helixcode.com
http://lists.helixcode.com/mailman/listinfo/gnome-print