-
Notifications
You must be signed in to change notification settings - Fork 4
/
Foomatic-Devel-Ideas.txt
240 lines (186 loc) · 7.22 KB
/
Foomatic-Devel-Ideas.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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
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 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>