We have waited for comments on registered parameters until last Friday.
The common tenor was to go with technical classifications based on numbers
and attributes and not try map that to a global list.
The decision is to go with that approach. I hope we'll be able to solve all
problems coming up by that.
I like to keep the format as clear as possible and not overloaded with nice,
but redundant information. I want driver developers to expect a clear and
transparent format to work with. So we will not save IPP or other keywords
for paper sizes after this decision.
We do not want to stop with the pure specification of the UPDF format. We
already agreed that we will provide documentation on how to use the
different fields and values best.
Additionally the group is tending to give more help to driver developers.
For now I do not promise sample source code.
But things like Jim Lo's list of paper sizes is exactly what I mean by
additional help. Putting together such overviews will be the exact help a
driver developer is looking for. We may add this list to our documentation
on our web site. Perhaps we'll create a special directory like "Driver
developement recommendations".
I will contact Jim today to find out, whether he is willing to accompany the
format as a kind of print media expert. Maintaining that list would be one
of the tasks.
I'd like to see the list being unique. An Executive paper size should have
exactly one value in our list. If a device has a different implementation
with other values it will not be detected as the standard Executive paper
size, although it could be considered a predefined custom paper size with
the same name by drivers.
If in doubt I like clear and unique information more than ambivalent
documentation, which will not provide the quick orientation people are
looking for. I do not like but I'm willing to buy some disadvantages for
that.
To stay with this sample we will reflect all necessary attributes in the
UPDF format.
I would like to add some recommendations how to round paper sizes to
standard sizes in drivers (define an error range). BTW: This would be a nice
area for some sample code, which likely exists already at a number of
places. Just keep a number of #define outside the code like
StandardSizeErrorRange and UnitRelatedErrorRange (perhaps even per typical
unit like inch, mm, etc). Input parameters may be just a pointer to a value
(relative to mm/1000, which will be the UPDF unit) and perhaps a unit const
(relative to mm/1000; a sample value for mm would be 1000). The return value
would be a driver and therefore OS specific standard size or NULL. A driver
would refer to his list of standard sizes (structure with OS_ID, width and
height in mm/1000). The value may be reset, if discovered as a standard
size, as the OS standard size is assuming a slightly different value, or
recalculated because of unit related rounding. If anybody will contribute
such a small piece of code, we would add it to the recommendations.
Regards
Norbert Schade
Oak Technology, Inc.
Imaging Group
10 Presidential Way
Woburn, MA 01801-1041
USA
phone: 1-781-638-7614
fax: 1-781-638-7555
email: norbertschade@oaktech.com
This archive was generated by hypermail 2b29 : Wed Nov 22 2000 - 11:36:46 EST