01-att1.htm
Norbert,
So
your proposal is to always use one set of units, namely 1000ths of a mm (i.e., a
micrometer); never use inches for any media sizes. It certainly is
simple.
1000th
of a mm is precise enough so that the English sizes can be represented in
1000ths of a mm without round off error (which would create differences in
names, if some rounded and others truncated).
We
used the same strategy of using only a single unit system in the IPP Production
Printing Attributes - Set1 extension, instead of having both metric and
English. The only minor difference was that we used 100th of a mm,
instead of 1000th of a mm for use in the "media-size" member attribute of the
"media-col" attribute. We felt that was precise enough. See section
3.13.8 in:
ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf,
.doc, .rtf
The
1000th of a mm is one of the two units used in the Printer MIB (the other
being 10000th
of an inch).
We
did agree at the meeting that the client shouldn't simply display the Media
Size name to the user if it doesn't have it in its localization data base
(thought there will always be simple minded clients that will). The
client should do some parsing and possible converting of units to the one that
the user prefers. So there is no real advantage to the client to have the
units be in inches for English sizes and metric for metric sizes (except for the
really simple clients that never convert units).
What
do others think of just always using micrometers for the size dimensions for our
Media Size Self Describing Names?
Tom
I have my problems with the new
proposal.
I am going to rephrase my previous statements
commenting that proposal.
Splitting the media size name into three
components (unit, name, dimensions) is a very new idea.
My main problem with this proposal is the first
component.
In Ron's current version of the spec we have two
units: inch/1000 and mm/10. We have implemented that version to learn
about problems.
With the new proposal there is the danger to have
an even bigger number of units.
Supporting more than one unit is a serious
problem for any driver. Ask any driver developer. It's not about what unit I
want to show in the UI. It's about necessary conversions when dealing
with applications. Please study Mark's feedback from 4/20. I repeat it in easy
words (I hope).
Scenario excerpt
1. Workstation 1 with driver 1
Driver 1 is supporting a media size
'Letter.2159-2794' (the developer of the driver has chosen the metric way).
You could do the sample with any other size.
2. User 1 sitting at workstation 1 writes
one page of text with application xyz and saves the document.
this means that the size information
'Letter.2159-2794' is saved in the document file as well in many, many
applications.
3. User 1 sends his document to user
2.
4. User 2 sitting at workstation 2 with driver 2
(different from driver 1) opens the document. This second the driver 2 is
already involved.
5. Imagine driver 2 is not supporting
'Letter.2159-2794', but 'na-Letter.8500-1100' instead, which in fact is the
same size with a different name.
Now it's the question what is driver 2
doing.
It could start some investigation to match or
emulate the required size. -> bad performance.
The same situation will happen again when
printing. It will happen very often, repeatedly.
So we already have a problem with two units. If
we now open a gate to be able to define even more units, it will be aweful
code and a terrible performance. Every driver developer should be able to
prove that.
However everything would be fine, if there'd be
one and one only unit.
Make it small enough that any rounding for a UI
string or whatever is needed, can be done properly. Our proposal within UPDF
was mm/1000, which is certainly small enough (and used in the industry
anyhow).
I treated strings like 'jis' or 'iso' just as
parts of the name to make it more apparent. 'na' was the only exception so
far.
If all names are unique (I think they are in
Ron's current concept), I don't have a problem splitting the name and the
dimensions into two components. In that case we may even work with the name
only and handle the dimensions with an include file.
I thought the idea of combining the name and the
dimensions is ok, as we need it for custom size anyhow.
BTW: I am happy to have proper keywords, but my
drivers certainly will never, never, never show them in the UI. Be also sure
that in UPDF we are providing the chance to assign a proper human readable UI
string to it.
So from a driver's point of view the easiest case
is to work with 1 unit (mm/1000), remove the prefix 'na-' and convert all the
dimensions.
This ensures a good performance, consistent
routines and readability.
Whatever the internal unit of a driver is, it
most probably has all converting routines available to work with 1 unit, but
not all necessary functions to match between different units.
I would be very surprised if Mark does not feel
very, very similarly, although I have been told differently today.
Unfortunately I couldn't get hold of him on his trip today.
I call this proposal '1unit mm/1000, unchanged
naming', where unchanged naming means no separate components, but converted
dimensions into that 1 unit. I do not insist on unchanged naming, but I
haven't seen the big advantage of it so far.
Regards
Norbert Schade
Principle Software
Engineer
Host Software Group
Oak Technology, Inc.
10 Presidential
Way
Woburn, MA 01801
USA
Phone: 1-781-638-7614
Fax:
1-781-638-7555
email: norbertschade@oaktech.com