Harry,
I would agree with you 100% if the list of classes were fixed or there was
no possiblity of new units of measure. In fact this was the basis of my
original proposal. Since the possiblity of new units of measure is now a
reality and we can never guarantee no new classes, we must uniquely identify
the units. If a new class is defined and it uses one of the existing units,
a client must be updated to be able to use the new class. If the units are
explicit, the client just ignores the class. The only time the client has a
problem is when a new class with new units is defined.
Ron
-----Original Message-----
From: Harry Lewis [mailto:harryl@us.ibm.com]
Sent: Thursday, May 03, 2001 10:12 PM
To: Bergman, Ron
Cc: 'don@lexmark.com'; Hastings, Tom N; ipp (E-mail)
Subject: RE: IPP> global media ... [put units field last]
Would seem trivial to map "classes" to "units". Seems cleaner to me than
assigning a special meaning to one prefix (na-).
Units called out separately (from "class") are redundant, but I suspect
are desired for the case of fall back to display of the "media size self
describing name" - (which we unanimously agreed in Portland was not
intended for human display).
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"Bergman, Ron" <Ron.Bergman@Hitachi-hkis.com>
Sent by: owner-ipp@pwg.org
05/03/2001 06:01 PM
To: "'don@lexmark.com'" <don@lexmark.com>, "Hastings, Tom N"
<hastings@cp10.es.xerox.com>
cc: "ipp (E-mail)" <ipp@pwg.org>, "'RonBergman@aol.com'"
<RonBergman@aol.com>
Subject: RE: IPP> global media ... [put units field last]
Don,
The one advantage I can see to the suffix, an application does not have to
be aware of all the possible "class" names. In my original proposal we
only
had to worry about inches and mm, so using "na" as a prefix to indicate
inches seemed to be a good solution. The application did not have to
understand the meaning of "iso", "jis", etc; only "na". To have the
ability
to add new units of measure with the Portland proposal means that the
application now must understand the meaning of "iso", "jis", etc. If a
new
class is defined that implies different units, such as light years, the
application will be aware that is not another class that uses mm. With
the
method agreed to yesterday the application only needs to understand "in"
and
"mm". If it wasn't for the desire to accommodate new units at some future,
I
would not be in favor of the latest change.
Mark VanderWiele, who was one of the instigators that resulted in the
Portland decision (although Mark was not present in Portland) favored this
choice over all the rest.
Also, the prefix is still present, which provides the class information,
and
I am adding the "om-" prefix to those names that did not previously
include
the prefix.
Ron
-----Original Message-----
From: don@lexmark.com [mailto:don@lexmark.com]
Sent: Thursday, May 03, 2001 11:13 AM
To: Hastings, Tom N
Cc: ipp (E-mail)
Subject: RE: IPP> global media ... [put units field last]
To Tom's "so called " advantages of having the units be explicit:
1) There is NO work difference between changing your code to know that the
suffix "ly" means light-years versus it knowing the prefix "NASA" means
light-years.
2) Every prefix we defined has implicit units so even if a piece of
software
has
never seen a new paper size, as long as the prefix is one of the defined
ones,
the units are know. If the units suffix is new (see "ly" example above)
there
is no guarantee that the average user would have a clue what know what the
units
abbreviation meant. Since we have the case covered for all the English
unit
and
Metric units, something else would have to be pretty obscure and would not
be
well known. If the user was in a specialized area that used a very unique
paper
size, he/she could probably just as easily determine that NASA measures
media in
light-years. He/she would certainly have no early idea what a twip was.
3) There is NO advantage one way or the other for this case. Unparsed,
unfiltered names have no guaranteed meaning in either case so place your
bets.
So, if I understand the process correctly, since I couldn't be on the call
yesterday it is my duty to stir the pot and point other 12 sigma and other
finge
cases that make my solution better??
**********************************************
* Don Wright don@lexmark.com *
* Chair, Printer Working Group *
* Chair, IEEE MSC *
* *
* Director, Alliances & Standards *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 859-825-4808 (phone) 603-963-8352 (fax) *
**********************************************
"Hastings, Tom N" <hastings%cp10.es.xerox.com@interlock.lexmark.com> on
05/02/2001 12:10:16 PM
To: "Don_Wright/Lex/Lexmark.LEXMARK"@sweeper.lex.lexmark.com, "McDonald,
Ira"
<imcdonald%sharplabs.com@interlock.lexmark.com>
cc: "ipp (E-mail)" <ipp%pwg.org@interlock.lexmark.com> (bcc: Don
Wright/Lex/Lexmark)
Subject: RE: IPP> global media ... [put units field last]
In answer to Don's good question: why do we keep re-hashing how the media
size units are represented:
The advantage of having the units explicitly represented in the Media Size
Self Describing Names are:
1. Allows for the possibility of other units being introduced sometime in
the future (though I hope not) without impacting deployed implementations,
which was brought up for the first time (to my knowledge) at the Portland
meeting last week.
2. These Media Size Self Describing Names can be used with currently
deployed IPP/1.1 clients and Printers; they are just more keywords and a
localization data base deals with them nicely, by just adding additional
keywords and their translations. However, if such an IPP client receives
a
keyword that it doesn't recognize (i.e., isn't in its localization data
base), its only choice is to display the keyword as it is to the user. So
the advantage of having the units in a human readable form, helps such a
case. The user doesn't have to know that a name starting with "na_" or
"oe_" means the numbers are in 100th of inches; otherwise, 1000th of mm.
(Using decimal fractions, makes such a fallback even more understandable
to
the human user, since the units are in inches or mm directly).
3. Very simple (or English only) systems (some UPnP client UCPs?) can just
take these Media Size Self Describing Names as is and display them to the
user for selection. With XHTML-Print, such UPnP client software doesn't
have to even know what the dimensions are; it just passes the Media Size
Name token selected by the user through to the Printer.
As to why do we keep re-hashing this: we have a smaller number of
participants, some of them are different from meeting to meeting, and, as
we
agreed in Portland, people didn't feel very strongly between methods b and
c
(the only two we considered at Portland). Finally, I don't believe that
we
have ever made a list of alternatives and made a choice.
Tom
-----Original Message-----
From: don@lexmark.com [mailto:don@lexmark.com]
Sent: Tuesday, May 01, 2001 22:07
To: McDonald, Ira
Cc: 'Hastings, Tom N'; Bergman, Ron; 'Wagner,William'; 'Harry Lewis';
Don Wright (E-mail); IPP Group; Norbert Schade; Mark VanderWiele;
'RonBergman@aol.com'
Subject: RE: IPP> global media ... [put units field last]
We don't need redundancy. Units are know based upon the class. Why oh
why
do
we continue to rehash this.
**********************************************
* Don Wright don@lexmark.com *
* Chair, Printer Working Group *
* Chair, IEEE MSC *
* *
* Director, Alliances and Standards *
* Lexmark International *
* 740 New Circle Rd C14/082-3 *
* Lexington, Ky 40550 *
* 859-825-4808 (phone) 603-963-8352 (fax) *
**********************************************
"McDonald, Ira" <imcdonald%sharplabs.com@interlock.lexmark.com> on
05/01/2001
07:27:03 PM
To: "'Hastings, Tom N'"
<hastings%cp10.es.xerox.com@interlock.lexmark.com>,
"Bergman, Ron" <Ron.Bergman%Hitachi-hkis.com@interlock.lexmark.com>,
"'Wagner,William'" <wwagner%netsilicon.com@interlock.lexmark.com>,
"'Harry
Lewis'" <harryl%us.ibm.com@interlock.lexmark.com>, "Don Wright
(E-mail)"
<"Don_Wright/Lex/Lexmark.LEXMARK"@sweeper.lex.lexmark.com>
cc: IPP Group <ipp%pwg.org@interlock.lexmark.com>, Norbert Schade
<norbertschade%oaktech.com@interlock.lexmark.com>, Mark VanderWiele
<markv%us.ibm.com@interlock.lexmark.com>, "'RonBergman@aol.com'"
<RonBergman%aol.com@interlock.lexmark.com> (bcc: Don
Wright/Lex/Lexmark)
Subject: RE: IPP> global media ... [put units field last]
Hi,
YES - put the optional units field _last_. This is a good idea!
Cheers,
- Ira McDonald
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Tuesday, May 01, 2001 1:49 PM
To: Bergman, Ron; 'Wagner,William'; 'Harry Lewis'; Don Wright (E-mail)
Cc: IPP Group; Norbert Schade; Mark VanderWiele; 'RonBergman@aol.com'
Subject: RE: IPP> global media; comment on yesterday's proposal [put
units field last]
Ron,
A slight variation on your proposal to make the units an explicit field in
order to make the names completely self describing, would be to move it
from
being the first field to being last field. Then it could be displayed by
very simply by (dumb) clients that didn't localize the names and/or
recognize a new name without any processing (or by simply replacing any
underscores with a space):
Examples: na-letter_8.5-11_in
iso-a4_210-297_mm
Bill sees the explicit units as redundant, which they certainly are and we
don't want people to think that the following names are synonyms,
respectively:
na-letter_215.9-279.4_mm
iso-a4_8.2677165354330708661417322834646-11.692913385826771653543307086614_i
n
On the other hand, this approach of explicitly passing the units in a
separate field does allow us to add other units in the future without
risking any confusion with existing implementations that only know about
the
in and mm field values.
Tom
-----Original Message-----
From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
Sent: Monday, April 30, 2001 17:25
To: 'Wagner,William'; Bergman, Ron; 'Harry Lewis'; Hastings, Tom N; Don
Wright (E-mail)
Cc: IPP Group; Norbert Schade; Mark VanderWiele; 'RonBergman@aol.com'
Subject: RE: IPP> global media; comment on yesterday's proposal
Bill,
Thank you for the explanation. I am sure this was extensively
discussed at the meeting and I wish I could have attended.
I have no problem with the concept of "class". It certainly is cleaner
than my original proposal of "na indicates the dimensions are in inches
and all others are metric." And I also agree that the concept of class
allows possible future expansion.
As long as we are adding the "class" part it should be very well
defined as to the meaning of the classes. Since we really only have
2 classes currently defined, I would suggest that they be called:
'inch' or 'in' for the class that specifies inch dimensions.
'millimeters' or 'mm' for the class that specifies mm dimensions.
Examples: in_na-letter_8.5-11
mm_iso-a4_210-297
Although this results in a longer total name, I feel it is cleaner
and does not require a parser in a simple printer to decode a large
number of names for metric sizes. And I don't see how this breaks
the ability to add additional sizes in the future. In fact, this
allows a device to quickly recognize that it does not understand the
class if another class is defined. And it may prevent problems, since
under the Portland agreement the device may look for 'na' as inches
and anything else as millimeters.
Ron
-----Original Message-----
From: Wagner,William [mailto:wwagner@netsilicon.com]
Sent: Monday, April 30, 2001 4:15 PM
To: 'Bergman, Ron'; 'Harry Lewis'; Hastings, Tom N; Don Wright (E-mail)
Cc: IPP Group; Norbert Schade; Mark VanderWiele; 'RonBergman@aol.com'
Subject: RE: IPP> global media; comment on yesterday's proposal
Ron,
I think the point is that the "Class" is already required in most of the
instances as part of the common name (NA, iso, jis, etc.) The units are
implicit in the class, but are not the only reason for the class. This is
what was done before. The only change was to make this relation more
clear,
consistent and expandable by representing class as a separate field and by
defining classes for those few sizes that did not already have one
associated. The reason that there are many classes identified are that
there are many classes in common use. And yes, one of the objections made
to
the original proposal was that it did not allow for other units; allowing
that is a by-product of the proposed approach; it is not the primary
intent.
Bill Wagner
-----Original Message-----
From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
Sent: Monday, April 30, 2001 4:45 PM
To: 'Harry Lewis'; Hastings, Tom N; Don Wright (E-mail)
Cc: IPP Group; Norbert Schade; Mark VanderWiele; 'RonBergman@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@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@cp10.es.xerox.com>
Sent by: owner-ipp@pwg.org
04/27/2001 05:22 PM
To: Norbert Schade <norbertschade@oaktech.com>
cc: IPP Group <ipp@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@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@oaktech.com
This archive was generated by hypermail 2b29 : Fri May 04 2001 - 11:22:38 EDT