IPP Mail Archive: RE: IPP> Minutes of telecon to decide on P

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

From: pmoore@netreon.com
Date: Mon May 07 2001 - 14:54:17 EDT

  • Next message: don@lexmark.com: "RE: IPP> Minutes of telecon to decide on PWG Media Size syntax, Wed, 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@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