Ah, the joys of trying to combine human readable and machine readable data.
I still dont understand why you dont just have a human readable media
description ("A4 bond - very nice but expensive", "recycled letter"), that is
free format and localized - the intent is to allow a user to directly select one
of them.
If an app wants real data about the media then provide explicit queryable
machine readable attributes - media-size, media-color, media-weight.
Alternatively if the protcol is not rich enough to provide these attribute then
provide two attributes - media-info (machine readable) and media description
(human readable). Media-info would be a structured string syntax but there would
be no argument about how readable it is (how about
"szx=8in,szy=11in,wt=12g,mfg=kodak")
Otherwise somebody will have to hand out laminated cards with the ABNF syntax
explained whenever I visit Laptop Lane.
"Hastings, Tom N" <hastings@cp10.es.xerox.com> on 05/07/2001 11:19:30 AM
To: don@lexmark.com
cc: "ipp (E-mail)" <ipp@pwg.org>, "Mark VanderWiele (E-mail)"
<markv@us.ibm.com> (bcc: Paul Moore/AUCO/US)
Subject: RE: IPP> Minutes of telecon to decide on PWG Media Size syntax, W ed,
May 2 [class vs. explicit units]
Don wrote:
"No advantage to explicit units."
The flaw that we saw at the telecon to using class names (or prefix) to
indicate units implicitly, rather than having units explicitly represented,
is that we *will* add new class names as the need arises, but we are very
unlikely to add new size units.
Why do you think we won't add new class names in the future?
The size units are baked into the ABNF as "in" and "mm", so adding new size
units will take a major revision of the standard, not just adding new names.
We also don't add a name for size that is already present, but differs only
in units. However, I think we all assumed that new class names (or prefix
names) would be added as needed, without any change to the ABNF or to the
code of conforming clients and Printers. Adding new units will change the
ABNF and will change the code of most clients and Printers.
While most new class names will be metric, there is no guarantee that the
only two English unit class names: "na-" and "oe-" will be the only English
class names that we ever have. We may need some additional English class
names. But how could a client that is trying to do a good job and localizes
the units by converting all units to what the user wants before displaying
them do with an unrecognized class name? Assume that it is metric? But
what if the new class name were really an English units class name?
It was that reasoning at the telecon that caused us to abandon the class
name with implicit units. (I had tried retain the class name, but
suggesting that we could freeze forever the English class names at "na-" and
"oe-", but the group thought that was a bad idea, so I abandoned that
approach to saving the class name to imply units).
And even in the very unlikely situation that we do agree to add more units
(and add those units to the ABNF), a client will be able to know for certain
that it doesn't know what the units are and will *avoid* making a mistake
when converting the unknown units to its internal representation. With the
class idea, the client would be forced to assume that an unrecognized class
name was still metric and make a mistake, or not be able to handle new class
names (which would be unfortunate, since we expect to add class/prefix names
as the need arises and we don't need to change the ABNF to do so).
Finally, even in the very unlikely situation that we do agree to add more
units (and add those units to the ABNF), for client software that doesn't
care what the size is because they are using XHTML-Print, the units are only
of interest to the human user. So the user will either know what the new
units are ("AN" is angstroms, or that "LY" is light years,
or that "TW" is twips) and will be able to choose or won't know what the
units are and so won't choose that size from the list that the Printer
supplied to the client.
Remember we won't add a size name to the standard that differs only in its
units. So it would only be new sizes that could get new units, anyway.
Ok that the units are explicit and are limited today by the ABNF to "mm" and
"in"?
Tom
-----Original Message-----
From: don@lexmark.com [mailto:don@lexmark.com]
Sent: Monday, May 07, 2001 10:36
To: Hastings, Tom N
Cc: ipp (E-mail); Mark VanderWiele (E-mail)
Subject: RE: IPP> Minutes of telecon to decide on PWG Media Size syntax,
W ed, May 2 [define all possible units]
Tom, et al:
a) I believe new class names (over and above the PDX list) are no more
likely
than new dimensional units.
b) I don't see any difference here. What's the difference between being
independent of the "class" versus a worthless "in" or "mm" appendage?
c) no difference between the two options... same behaviour works in either
case.
No. We do not have any agreement.
**********************************************
* 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/07/2001 01:29:15 PM
To: "Don_Wright/Lex/Lexmark.LEXMARK"@sweeper.lex.lexmark.com
cc: "ipp (E-mail)" <ipp%pwg.org@interlock.lexmark.com>, "Mark VanderWiele
(E-mail)" <markv%us.ibm.com@interlock.lexmark.com> (bcc: Don
Wright/Lex/Lexmark)
Subject: RE: IPP> Minutes of telecon to decide on PWG Media Size syntax, W
ed,
May 2 [define all possible units]
Don,
I'd like to strongly object to your other suggestion (below) that we define
all possible units now. There is definitely no need to do so. We can wait
to see if any other units are ever needed. I don't frankly think it is
likely. The units are only to identify the media as part of a name. We have
the units baked in as part of the ABNF, so it is clear that we don't intend
to add new units, except by a major revision of the standard.
But the advantage of having the units explicitly present are the following:
a. Your suggest was to use the class name to imply units. But there *will*
be new class names added. So having the units implied by the class name
will be very unreliable. The best a client could do was to *assume* that an
unrecognized class name was metric and that we would never add any new class
names for english (besides "na- and "oe-"). But that is a very weak
guarantee.
b. A good client that gets an recognized Media Size Self Describing Name,
can parse out the dimensions, and using the units field convert the values
to the units (1) to its preferred internal format for the driver and (2)
that the users prefers when displaying the media size choices to the user.
This conversion will be independent of the class fields and we can add any
new class fields as they are needed without disrupting any conversion that
clients will do.
c. For a client that doesn't recognize the name, because there are some new
units (very unlikely in my opinion, but possible), it can display the entire
string to the user. In the case, the client will be out of luck to convert
to its internal set of units for the driver.
So do we have general agreement that the units should be explicitly part of
the name, and that only "in" and "mm" are allowed in the ABNF?
Tom
-----Original Message-----
From: don@lexmark.com [mailto:don@lexmark.com]
Sent: Thursday, May 03, 2001 13:16
To: Hastings, Tom N
Cc: ipp (E-mail); Mark VanderWiele (E-mail)
Subject: Re: IPP> Minutes of telecon to decide on PWG Media Size syntax,
Wed, May 2
I most strongly disagree with this decision. I believe the Portland
decision:
na_letter_8.5-11, iso_a4_210-297
or the Maui direction are the correct answers!!
What does "x" mean? Why do we have an alphabetic character in the middle of
a
dimensional string? Does it have any intrinsic meaning to non-English
speakers?
What will it mean to someone in China when the paper size is shown as
"8.5x11in"
for all the cases that keep getting brought up where the name will be
blasted to
the screen without filtering and parsing? If we are going to explicitly
include
units, we should define the abbreviations for all units ever known or that
could
ever be invented so an application written today will know how to interpret
this
information 20 years from now.
I intend to continue to lobby against this and to vote NO when it goes
through
the last call process.
**********************************************
* 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 07:30:01 PM
To: "ipp (E-mail)" <ipp%pwg.org@interlock.lexmark.com>
cc: "Mark VanderWiele (E-mail)" <markv%us.ibm.com@interlock.lexmark.com>
(bcc:
Don Wright/Lex/Lexmark)
Subject: IPP> Minutes of telecon to decide on PWG Media Size syntax, Wed,
May 2
Minutes of telecon to decide on PWG Media Size syntax, Wed, May 2
Attendees: Mark VanderWiele (IBM), Ron Bergman (Hitachi Koki Imaging
Solutions), Melinda Grant (HP), Ira McDonald (High North), Bob Herriot
(Xerox), Bill Wagner (NetSilicon), Carl-Uno Manros (Xerox), and Tom Hastings
(Xerox)
We also had rankings of the media size alternatives from: Don Wright
(Lexmark).
1. Summary
We covered three issues:
A. The syntax for the Media Size Self Describing Names
We unanimously agreed to method a (iso-a4_210x297mm, na-letter_8.5x11in),
since it does help the simple client with a simple fallback presentation to
the user for unrecognized names and can still be easily parsed and processed
by new client software.
B. Merging the Media Finish Names into Media Type Names (decision at
Portland)
We did reaffirm that adding the 'photographic-xxx' type names, where 'xxx'
is glossy, high-gloss, semi-gloss, satin, and matte, is ok.
C. Adding some commonly used Media Type Names, such as bond and recycled
We agreed to add stationery-bond and stationery-recycled to go along with
stationery-inkjet.
We also agreed that a future project should attempt to produce a way to
collect all of the media attributes, including MediaType, MediaSize,
MediaColor, and others, like weight and imagable area (which is
printer-dependent), into a single collection, perhaps using XML. So we did
not want to add things to the Media Type which are kept separate in current
systems.
We also agreed that we wanted to complete this standard in the next week or
two, ready for final voting. Ron will publish the next version over the
weekend and we will probably have one more version a week after that to be
voted on. Because of the unanimity of the Media Size syntax decision, we
feel that this decision will stick and that the standard can move forward.
2. Details of the syntax for the Media Size Self Describing Names
We considered the following 5 alternatives as published in the meeting
announcement. No one had any additional alternative to add.
a. original UPnP/HTML way (but with _ field separator): iso-a4_210x297mm,
na-letter_8.5x11in
b. Maui (D03-D07) way: iso-a4.2100-2970, na-letter.8500-11000
c. Portland decision: iso_a4_210-297, na_letter_8.5-11
d. All 1000ths of mm: iso-a4.210000-297000, na-letter.215900-279400
e. Units as a separate third field: iso-a4_210-297_mm, na-letter_8.5-11_in
We reaffirmed that the Media Size Self Describing Names are primarily for
program to program communication, such as from a Printer to a client, a
client to a Printer, or from a data description file to a client. Also that
a recipient of a name need only do a straight string comparison to see if it
recognizes the name; in comparisons of the dimension part it need not
perform any unit conversion, rounding, or closest size match.
The dimension part of the Media Size Self Describing Names are not intended
for internal use within a program. However, we also clarified that when a
client receives a Media Size Self Describing Name that it does not recognize
(either by parsing or straight string match), it is very useful for that
client to be able to display the string to the user. Therefore, if the
units are explicitly expressed, then the user will more readily understand
the fallback presentation from the client.
Mark also explained that in his experience, the client does not bother to
localize the Media Size Names for the user, except for the units, since the
names are fairly independent of human language. So the client needs to be
able to easily parse and convert the dimensions to the user's units for an
unrecognized size name. Having the units expressly provided helps such
fallback conversion no matter how many classes are added in the future.
Also by having the units explicitly expressed, if there ever are new units
added, they will not be confused with the two existing units (in and mm).
Therefore, we agreed that only alternative a or e met the requirements.
We then unanimously agreed to method a, since it was more user friendly for
the fallback display case and not much harder to parse than method e.
We also agreed that in order to be able to do a straight character for
character string match of the entire Media Size Self Describing Names string
including custom names, the fraction part must not have trailing zeros (and
the decimal point must be omitted if there is no fraction part), i.e.,
na-letter_8.5x11in, NOT na-letter_8.50x11.in
BTW, this syntax is the same as the original UPnP BasicPrint Template Media
Size syntax, with the single change that the media name field is separated
from the dimensions by the underline character (_) , instead of by the
hyphen (-), providing a more straightforward parsing algorithm, since the
media name field can have hyphens too. So the UPnP group should be happy
with our decision as well.
3 Details of merging the Media Finish Names into Media Type Names (decision
at Portland).
At Portland, we recognized that having separate Finish Names, while good for
new standards, such as IPP Production Printing extension and JDF, which have
separate attributes for front and back coating, it does not help existing
implementations of print systems and protocols, which have only the Media
Type, Media Size, and Media Color mechanism. Even IPP/1.1 has only the
"media" Job Template attribute mechanism which can carry both Media Type
Names and Media Size Self Describing Names. So at Portland, we agreed to
fold back the Finish Names into sub-types of the photographic Media Type,
since we though that the primary use for the coatings (glossy, matte, satin,
etc.) was for photographic paper. The definitions are:
stationery
Separately cut sheets of an opaque material
stationery-coated
Separately cut sheets of an opaque material with a coating of unspecified
type
stationery-inkjet
Separately cut sheets of an opaque material whose coating is designed to
minimize the spread of liquid inks
photographic
Separately cut sheets of an opaque material to produce photographic quality
images. The coating is unspecified.
photographic-glossy
Separately cut sheets of an opaque material that has a "glossy" coating to
produce photographic quality images.
photographic-high-gloss
Separately cut sheets of an opaque material that has a "high-gloss" coating
to produce photographic quality images.
photographic-semi-gloss
Separately cut sheets of an opaque material that has a "semi-gloss" coating
to produce photographic quality images.
photographic-satin
Separately cut sheets of an opaque material that has a "satin" coating to
produce photographic quality images.
photographic-matte
Separately cut sheets of an opaque material that has a "matte" coating to
produce photographic quality images.
photographic-film
Separately cut sheets of film used to produce photographic quality images.
back-print-film
Separately cut sheet of a translucent film that the user can view with or
without backlighting.
After discussing the criteria for adding a Media Type Name, there was
general agreement that the criteria for adding a Media Type name should be
one of:
a. If the client software or Printer can alter its actions based on a Media
Type Name, then it is a candidate for addition. For example, if the way the
ink is put down would be altered (in some implementations) by a proposed
Media Type Name, then that name should be added.
b. If the user would like to choose between two different Media Type Names,
even if the client or Printer does not behave any differently for the two,
then that name should be a candidate.
Also extra weight should be given to a Media Type that is used in existing
systems should be another criteria and we should not add theoretical values,
if they aren't used in real systems.
ACTION ITEM (Tom): Check with office equipment stores to see if there are
coatings for both photographic and for more ordinary paper.
ACTION ITEM (Melinda): Check with HP experience in this area as well.
There was some concern that there might be some use of the 'xxx' coating
parameters defined for 'photographic' with the 'stationery' Media Type as
well.
Bob pointed out that there will be a gateway mapping problem between systems
that have only the Media Type mechanism and ones (like IPP Production
Printing Extension - see IEEE-ISTO 5100.3-2001 and JDF), that keep the
Finish attribute separately from the rest of the other Media Type values
(and can keep them separate for front and back sides as well, where some
media might have different finish for front and back).
However, these additional media attributes are only OPTIONAL for a Printer
to support, so what happens when the Printer implements the Media Type
attribute, but doesn't implement the "media-coating-back" and
"media-coating-front" attributes? Can such implementations then use our
photographic-glossy, photographic-matte, values, or does that mean that the
Printer cannot represent the media finish at all? Is it better to have two
standard ways to do something (so that gateways can be implemented), or only
one way, but half the systems have to do something non-standard in order to
get the required functionality? We agreed to keep the new
'photographic-xxx' values, because of their use in existing systems and
emerging standards that don't have separate finish media attributes.
4. Details of adding some commonly used Media Type Names, such as bond and
recycled
IBM has proposed a list of additional Media Type Names that they have found
in various printers and print systems over the years. Two of them are also
prevalent in other existing systems: bond and recycled.
We discussed adding them to the Media Type. We agreed that they should be a
sub-type of stationery. While a person can buy recycled envelopes in a
store, we did not know of a print system in which the user could select
between 'envelopes' and 'envelopes-recycled'. Usually, the envelopes are
either recycled or they aren't as decided by the system administrator, so we
did not agree to add 'envelopes-recycled' to Media Type Names. Although
there was the same concern over recycled and bond that was expressed above
in finish that recycled should be a separate media attribute and bond should
be a separate stock type media attribute. The IPP Production Printing
Extension (IEEE-ISTO 5100.3-2001) has a separate "media-recycled" media
attribute with keyword values. JDF has a separate Recycled media attribute
with a boolean value and a Stock Type media attribute with values: Bristol,
Cover, Bond, Newsprint, Index, Offset - this includes book stock, Tag, Text.
In spite of this concern, we still agreed to add recycled and bond as
sub-types of stationery, i.e., 'stationery-bond' and 'stationery-recycled'.
Tom and Ron
editors of the PWG Media Standardized Names standard
This archive was generated by hypermail 2b29 : Mon May 07 2001 - 14:57:26 EDT