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

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

Re: IPP> Minutes of telecon to decide on PWG Media Size syntax, Wed, May 2

From: Mark VanderWiele (markv@us.ibm.com)
Date: Fri May 04 2001 - 11:47:19 EDT

  • Next message: Thomas, John: "RE: IPP> global media ... [put units field last]"

    Don: I just looked in one of lexmark'sChinese drivers and it displays "A4
    (210 x 297)" for the size. Same for Taiwan.

    Mark VanderWiele
    IBM, Linux Technology Center
    512-838-4779, t/l 678
    email: markv@us.ibm.com

    don@lexmark.com on 05/03/2001 03:15:52 PM

    To: "Hastings, Tom N" <hastings@cp10.es.xerox.com>
    cc: "ipp (E-mail)" <ipp@pwg.org>, Mark VanderWiele/Austin/IBM@IBMUS
    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

    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
    What will it mean to someone in China when the paper size is shown as
    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
    units, we should define the abbreviations for all units ever known or that
    ever be invented so an application written today will know how to interpret
    information 20 years from now.

    I intend to continue to lobby against this and to vote NO when it goes
    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>
          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

    We also had rankings of the media size alternatives from: Don Wright

    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
    by new client software.

    B. Merging the Media Finish Names into Media Type Names (decision at

    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

    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

    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,
    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
    a recipient of a name need only do a straight string comparison to see if
    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
    (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
    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
    new standards, such as IPP Production Printing extension and JDF, which
    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,
    etc.) was for photographic paper. The definitions are:

    Separately cut sheets of an opaque material

    Separately cut sheets of an opaque material with a coating of unspecified

    Separately cut sheets of an opaque material whose coating is designed to
    minimize the spread of liquid inks

    Separately cut sheets of an opaque material to produce photographic quality
    images. The coating is unspecified.

    Separately cut sheets of an opaque material that has a "glossy" coating to
    produce photographic quality images.

    Separately cut sheets of an opaque material that has a "high-gloss" coating
    to produce photographic quality images.

    Separately cut sheets of an opaque material that has a "semi-gloss" coating
    to produce photographic quality images.

    Separately cut sheets of an opaque material that has a "satin" coating to
    produce photographic quality images.

    Separately cut sheets of an opaque material that has a "matte" coating to
    produce photographic quality images.

    Separately cut sheets of film used to produce photographic quality images.

    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
    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
    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

    Bob pointed out that there will be a gateway mapping problem between
    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
    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

    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
    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
    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
    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:
    Cover, Bond, Newsprint, Index, Offset - this includes book stock, Tag,
    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 : Fri May 04 2001 - 11:47:45 EDT