Foomatic-Devel-Ideas.txt 7.22 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22



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.

23
The web interface of OpenPrinting could have buttons than where
24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240
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>