IPP> Minutes of telecon to decide on PWG Media Size syntax, W ed, May 2 [class vs. explicit units]

IPP> Minutes of telecon to decide on PWG Media Size syntax, W ed, May 2 [class vs. explicit units]

Harry Lewis harryl at us.ibm.com
Tue May 8 00:16:11 EDT 2001


Yea, verily!
---------------------------------------------- 
Harry Lewis 
IBM Printing Systems 
---------------------------------------------- 




pmoore at netreon.com
Sent by: owner-ipp at pwg.org
05/07/2001 12:54 PM

 
        To:     "Hastings, Tom N" <hastings at cp10.es.xerox.com>
        cc:     don at lexmark.com, "ipp (E-mail)" <ipp at pwg.org>, "Mark VanderWiele (E-mail)" 
<markv at us.ibm.com>
        Subject:        RE: IPP> Minutes of telecon to decide on PWG Media Size syntax, W ed, May 
2 [class vs. explicit units]

 



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 at cp10.es.xerox.com> on 05/07/2001 11:19:30 AM

To:   don at lexmark.com
cc:   "ipp (E-mail)" <ipp at pwg.org>, "Mark VanderWiele (E-mail)"
      <markv at 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 at lexmark.com [mailto:don at 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 at 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 at 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 at interlock.lexmark.com>, "Mark 
VanderWiele
      (E-mail)" <markv%us.ibm.com at 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 at lexmark.com [mailto:don at 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 at 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 at interlock.lexmark.com> on
05/02/2001 07:30:01 PM

To:   "ipp (E-mail)" <ipp%pwg.org at interlock.lexmark.com>
cc:   "Mark VanderWiele (E-mail)" <markv%us.ibm.com at 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


















More information about the Ipp mailing list