Statements to be decided:
1. Virtual units
Every UPDF has a basic field ID_M_VirtualUnit.
Sample parameter: 7200.
Conceptional idea: The universal driver will work with this virtual unit
for most of the variable parameters for print output without further
caring for resolutions in the UPDF.
Sample 1: Horizontal positioning
Target: To be able to define formulas, which generally tell about the
specific unit to calculate in. The formulas will be handled by a driver
routine called ParameterConverter (quite simple routine).
Sample formula for horizontal positioning (final syntax to be agreed
on):
esc * p formula(ID_M_HorizontalPosition * ID_M_DeviceResolution /
ID_M_VirtualUnit) X
Rounding and truncating to be discussed.
Print output: correct positioning command sequence for the current
device resolution in consistent units overall the complete driver. Can
be reused for future models, which may even work in higher device
resolutions.
Sample 2: Specification of width values for bitmap fonts
Sampe char: "A"
Assumption: the width of "A" is 20 pixel in 300 dpi
Specified value in UPDF: 480 (comment: 7200 / 300 = 24).
Advantage: 480 virtual units are valid for each device resolution (300
dpi, 600 dpi, even future resoutions).
Conclusion: This would unify a lot of parameter specifications. A
universal driver can nearly always think in virtual units. The
implementation of future models with higher resolutions saves a
tremendous time. If the parameter spec is correct once, it must be
correct for other future device resolutions working with the same
virtual unit. This will dramatically decrease test and maintenance
effort.
2. ID-classification
Sample ID's: ID_M_VirtualUnits, ID_M_HorizontalPosition,
ID_M_PaperSource, ID_M_PaperSize, ID_O_PrintMedia, ID_P_HolePunching
Legend:
M_ Mandatory. This ID is necessary to establish a correctly working
universal driver. The list will be defined by UPDF.
O_ Optional. This ID is not necessary to establish a correctly
working universal driver. One universal driver on one operating system
may support it, another driver on another operating system may not yet
support it. The ID may not be supported by any universal driver yet. But
it will make driver extensions more reliable. It will encourage
universal driver developers to support more optional ID's. The list will
be defined by UPDF. It may grow from time to time. Optional ID's may be
supported by one, some or all universal drivers.
P_ Proprietary. This ID may only be supported by proprietary drivers,
probably developed by a printer manufacturer while implementing the
rules of UPDF. This will be defined by e.g. a peripheral manufacturer.
A universal driver may support this control without knowing what it means,
if it is a simple toggle or something similar.
Conclusion: This is not really changing the way a universal driver will
work, but it makes it easier to write a UPDF looking at some lists.
Xionics' requirement: UPDF must be an open standard to allow proprietary
solutions while following the standard rules of UPDF. We do not assume
that the universal driver provided by every operating system fulfilles
all necessities of Xionics from beginning on.
We think this will heavily improve the acceptance of UPDF.
3. Parameter classification
Sample ID: ID_M_PaperSize
Sample parameters: Parm_G_Letter, Parm_G_A4, Parm_O_A5,
Parm_P_CompanyXYZFormat1, Parm_U_UserDefined1
Legend:
G_ Global. This parameter will be detected by every universal printer
driver. A side effect may be that the UI strings for those parameters
may be provided by the operating system to ensure consistent UI strings
throughout all drivers. A side effect may be that values for paper width
and length may be provided by the operating system to ensure consistent
values thtoughout all drivers. The list will be defined by UPDF. We will
define a range big enough for future extensions.
O_ Optional. This list will be defined by UPDF. It is not ensured
that a paper size with an optional parameter will be supported by an
operating system global UI string or global values. We will define a
range big enough for future extensions. If an optional parameter proves
its worldwide use over the times, it will be the target to move more of
these to the global list, until the global list is somehow complete.
P_ Proprieatary. This parameter may be defined by e.g. a printer
manufacturer. It is not ensured that a document saved with a proprietary
parameter for paper size will be detected later by another UPDF,
although the other one may support the same physical paper size, but
with a different parameter. Proprietary parameters may move to the
optional list after having proven its reliability and necessity. UPDF
will define a range for this list, but not the list itself.
U_ User defined. This list is not predefined at all. UPDF will define
a range for this list. These are reserved parameters for paper sizes
defined by the end user, if a certain paper source allows that.
Conclusion: I can imagine numeric values or alphanumeric values.
4. Tree structure of UPDF
One UPDF will define one model.
The UPDF is somehow a tree. I can well imagine several hierarchic levels
(e.g Fonts may be listed on level 1, while the font attributes, which
assemble a font, will be listed on level 2).
The universal driver will detect ID's by its name and may jump over ID's,
which definition it cannot completely support. This is the concept of an
open format. It allows to add branches to the tree without injuring correct
functionality of
other branches.
5. Unique and central definition per module
All specification is only done once. A module like a paper source ID is
specified in one block with all components.
5.1. A module may have a basic component.
5.2. A module may have a dialog component.
5.3. A module may have a print component.
5.4. Function call backs like initialization or specific functionality
may be a separate component or to be handled within the other
components.
5.5. Other components to be discussed.
Samples: ID_M_PaperSource and ID_M_PaperSize are typical modules for
5.1. (owns a list of paper sources), 5.2. (is represented in the dialog)
and 5.3. (some bytes have to be sent to the device).
A general printer language init (esc E) is a typical module for 5.3.,
but not necessarily for 5.1. and normally not for 5.2.
A group box is a typical module for 5.2., but not necessarily for 5.1.
and definitely not for 5.3.
6. Default driver settings
A standard problem of multilingual drivers provided for different
derivates of operating systems (International, East European, Arabic,
Japanese, etc.) is the default setting.
Standard problems to be solved for a universal driver are that not all
parameters are supported by some operating systems (e.g. Graphic modes
like Raster and GL/2 in PCL5e).
As we do not want to specify operating system specific defaults, we need
a kind of a fallback, which allows the definition of priorities.
Countries may require different defaults (e.g. Letter size for US, A4
for Europe).
A fallback mechanism may even help in this case. A ranking has to
be defined per country/language, which allow the global default
specification for each module per each country/language, even if some
elements may not be available under certain operating systems or certain
configurations.
We may think about grouping countries/languages to bigger groups like
Europe to avoid to many listings.
Feedback appreciated.
Sandra,
as these items are basic conceptional decisions, they must be clear right
from beginning. Perhaps we can agree on that in Miami.
Regards
Norbert