Here are some ideas on how new things could be implemented
----------------------------------------------------------

Suggested by Till

The items are not sorted in a special way, especially they are not
sorted by importance.


Conserving Foomatic data for certain distros or old driver versions
-------------------------------------------------------------------

This can be realized most easily by CVS tags which start a new
branch. When a distro or a driver is released one tags the CVS. So
retrieving this CVS state gives a Foomatic package fitting to the
appropriate distro or driver. Bug fixes for old distros or drivers
which do not apply any more to the current state of Foomatic can be
commited to the appropriate CVS branch.

The web interface of FSG OpenPrinting could have buttons than where
one can choose the driver or distro version for which one wants to
have the Foomatic data.


Printer compatibility classes
-----------------------------

Instead of needing to add many compatible printers to the drivers and
to the constraints of options one could introduce compatibility
classes. A compatibility class contains absolutely compatible
printers, which means printers which work with the same drivers, the
same options, and the same choices for the options. Then one can put
the class name into the list of supported printers of a driver and
also into the constraints of the options and so one avoids needint to
insert tenth of printers everywhere. Especially there are many HP
inkjets which are absolutely compatible to each other (around ten
classes instead of 100 printers) and there are many clones of HP
LaserJet printers.

The classes could be defined in a new subdirectory "class" besides the
existing "printer", "driver", and "option" subdirectories. The XML
file could look as follows (this is the class of new HP inkjets as
defined for the HPIJS driver. It contains only the "small" models with
paper sizes up to Legal format):

<class id="class/DJ9xxVIP_small">
  <printers>
    <printer>
      <id>printer/635698</id><!-- HP DeskJet 960C -->
    </printer>
    <printer>
      <id>printer/HP-DeskJet_980C</id>
    </printer>
    <printer>
      <id>printer/530418</id><!-- HP DeskJet 990C -->
    </printer>
    ...
  </printers>
</class>

Then the entry to include these printers in the HPIJS driver entry would
reduce to

  <printers>
    ...
    <printer>
      <id>class/DJ9xxVIP_small</id>
      <!-- HP DeskJet 990C compatible, max. Legal paper -->
    </printer>
    ...
  </printers>

The 1200-dpi photo quality choice is unique to this printer class, so
it will have the constraints:

    ...
    <constraints>
     <!-- Assume the choice doesn't apply... -->
     <constraint sense='false'>
      <driver>hpijs</driver>
     </constraint>
     <!-- ...except to these: -->
     <constraint sense='true'>
      <driver>hpijs</driver>
      <printer>class/DJ9xxVIP_small</printer>
     </constraint>
     <constraint sense='true'>
      <driver>hpijs</driver>
      <printer>class/DJ9xxVIP_large</printer>
     </constraint>
    </constraints>
    ...

This way the manual entering of Foomatic daya will get much easier.


Option conflicts
----------------

Option conflicts prevent the user from making choices which make
printing impossible or simply do not make sense (as Duplex on
transparencies or 1200 dpi on plain paper).

I have already thought about adding a fourth subdirectory (besides
"printer", "driver", "opt") named "conflict" containing files like

<conflict id="conflict/noLargeCapacityTray">
   <comments>
     <en>
        Large capacity tray not installed but either requested or needed
        due to the requested amount of copies.
     </en>
   </comments>
   <constraints>
     <constraint sense="false">
        <make>Brother</make>
     </constraint>
   <constraints>
   <conflicting_settings>
     <constraints>
       <constraint sense="false">
          <driver>ljet4</driver>
       </constraint>
     <constraints>
     <message>
       <en>
         Large capacity tray requested but not installed!
       </en>
     </message>
     <setting>LCTInstalled eq No</setting>
     <setting>InputSlot eq LargeCapacity Tray4 Tray5</setting>
   </conflicting_settings>
   <conflicting_settings>
     <message>
       <en>
         No tray for &value:Copies; sheets available!
       </en>
     </message>
     <setting>LCTInstalled eq No</setting>
     <setting>Copies gt 250</setting>
   </conflicting_settings>
</conflict>

Here "eq" means "equal to one of the items listed" and "gt" means 
greater than the given item. A conflict happens when all the conditions 
in the <settings> lines are fullfilled and it should show the <message> 
in the GUI. <constraints> mean the same as in the other files.


Graying out options
-------------------

Some options do not make sense when other options have a certain
setting, as for example adjustment of Cyan, Magenta, and Yellow when
grayscale or bw printing is chosen. So one could add conditions to an
option's XML file when it should be grayed out, as

<option type="int" id="opt/MagentaLevel">
  <grayout>
    <setting>ColorMode eq Grayscale BlackAndWhite</setting>
  </grayout>
  ...

The condition syntax is here the same as with the conflicts.


Standard and Advanced options
-----------------------------

A GUI could only show the standard options by default and the advanced
options only show up by clicking an "Advanced" button. This could simply
by realized by adding a

   <arg_advanced />

tag to all options which should be advanced options. Perhaps one
places it in the option constraints, so an option can be advanced for
one driver and standard for another.


Option groups
-------------

Option groups allow a more structured presentation of the options in a
GUI. In XPP (CUPS frontend) for example all options except "PageSize",
"InputSlot", "Duplex" go into an "Extra" group (this is a decision
made by CUPS when there are no group definitions in the PPD
file). With option groups there could be generated varipus tabs, as
"Finishing", "Color correction", "Installable options", ... which
would make it much easier to find the options in the GUI dialogs.

Options could be grouped by adding a group name to every option XML file:

<option type="enum" id="opt/pjl-stapling">
  <arg_group_longname>
   <en>Finishing Options</en>
  </arg_group_longname>
  <arg_group_shortname>
   <en>Finishing</en>
  </arg_group_shortname>
  <arg_longname>
   <en>Phone Number</en>
  </arg_longname>
  ...

We use a long name and a short name here, as for the option names
itself, one for the GUIs, the other internal identification or command
line applications.

In a PPD file the option entry would be surrounded by

   *OpenGroup: Finishing/Finishing Options

   ...

   *CloseGroup: Finishing

Options without group should be treated as before or get into some
default group.


Pickmany options
----------------

Pickmany options could have the same XML file structures as the "enum"
options but have the type "pickmany". They should allow to assign a
comma separated list of choices to the option:

   lpr -P laserjet -o option=value1,value2,value3 file.ps

The default value in the XML database entry file for this option
should contain a comma-separated list of choice IDs or can be empty:

   <arg_defval></arg_defval>

   <arg_defval>ev/choice1,ev/choice2</arg_defval>