Ron,
One possibility to simplify the class name idea for indicating the units is
to limit the class names that can have English to a fixed list and that any
other class name is metric (by definition). The fixed list of English class
names is:
na
oe (for other english)
A related comment is that the class name should be considered part of the
size_name field rather than a separate field separated by "_". Then the
current size names in use in IPP (iso-a4 and na-letter) are the same as the
first field (up to the first underscore character) in the Media Size Self
Describing Names, i.e., iso-a4_210-297 and na-letter_8.5-11. An
implementation that receives current IPP keyword names or the new Media Size
Self Describing Names, can simply parse the beginning of the token until the
"_" character or the end. If the name matches one that it recognizes, it
can (and should) ignore the dimensions that follow, if any. Changing the
"-" to "_" means that this simple parsing no longer works.
Also there will be confusion between the "-" and "_" in size_name by
implementers, administrators, and users; they look so much alike. It will
be very difficult to explain that there is an "_" between the class_name and
the rest of the size_name in iso_a4 and na_letter, but that the remaining
separators in the size_name are "-", such as in iso_a4-extra and
na_goverment-letter.
Finally, the problem with separating the class field from the size_name
field with the "_" field separater is that it gives the mistaken impression
that the dimension units are independent of the size_name, rather than being
part of the size_name. We don't have the following standard Media Size Self
Describing Names: iso_letter_215.900-279.400 and
na_a4_8.2677165354330708661417322834646-11.692913385826771653543307086614
Tom
-----Original Message-----
From: Bergman, Ron [mailto:Ron.Bergman at Hitachi-hkis.com]
Sent: Monday, April 30, 2001 13:45
To: 'Harry Lewis'; Hastings, Tom N; Don Wright (E-mail)
Cc: IPP Group; Norbert Schade; Mark VanderWiele; 'RonBergman at aol.com'
Subject: RE: IPP> global media; comment on yesterday's proposal
Harry,
I thought that Norbert's proposal was cleaner than the complicated
"class" proposal made in Portland. I have been trying to understand
the purpose of "class", other than to define the size. Unless, there
is another purpose, why do we need so many ways to indicate mm?
The need for iso, jis, jpn, prc, asme, and etc etc seems to make a
simple task vary complex.
I still prefer the definition of all sizes in their native dimensions,
rather than a conversion to a common base. But unless we can simplify
the "class" to just inches and mm, I would favor Norbert's method.
I like all the other suggestions from Portland, but this one does not
appear correct.
Ron
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Sunday, April 29, 2001 9:24 PM
To: Hastings, Tom N
Cc: IPP Group; Norbert Schade; Mark VanderWiele
Subject: RE: IPP> global media; comment on yesterday's proposal
This "shows to go ya" that we still don't (collectively) agree on the
purpose of the "self describing name". Seems the folks who write drivers
feel more natural operating in one set of units. (Norbets comments are
similar to those I received from our driver folks).
BUT....
in Portland (at least) we spent quite some time hammering out the intent
of this beast... which I would describe as...
STANDARD media size "names" with distinct elements ("class", "size name"
and "dimensions") in a (machine and developer-human) parsable syntax.
The "class" is supposed to indicate the units (typically inches or mm...
but hypothetically angstrom's or whatever if appropriate... which is
unlikely).
It would seem counter intuitive for "na_letter" to be represented in mm as
it is well known in the industry as "English".
Conversions are the realm of the application. If a driver wants to
(convert the English) and store everything in mm... that's OK... but the
STANDARD name should not change.
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"Hastings, Tom N" <hastings at cp10.es.xerox.com>
Sent by: owner-ipp at pwg.org
04/27/2001 05:22 PM
To: Norbert Schade <norbertschade at oaktech.com>
cc: IPP Group <ipp at pwg.org>
Subject: RE: IPP> global media; comment on yesterday's
proposal
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
-----Original Message-----
From: Norbert Schade [mailto:norbertschade at oaktech.com]
Sent: Thursday, April 26, 2001 13:50
To: IPP Group
Subject: IPP> global media; comment on yesterday's proposal
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 at oaktech.com