IPP Mail Archive: IPP> Minutes of the meeting on the PWG Med

IPP Mail Archive: IPP> Minutes of the meeting on the PWG Med

IPP> Minutes of the meeting on the PWG Media Standardized Names standa rd

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Apr 27 2001 - 18:25:03 EDT

  • Next message: Hastings, Tom N: "RE: IPP> ASME Y14.M metric Elongated Size and Extra-Elongated Siz es and a different ASME F size"

    I've also down-loaded these minutes to:

    ftp://ftp.pwg.org/pub/pwg/media-sizes/media-name-minutes-010424.doc

    Subj: Minutes of the meeting on the PWG Media Standardized Names standard
    From: Tom Hastings
    Date: 4/24/01
    File: media-names-minutes-010424.doc

    Attendees: Melinda Grant (HP), Bill Wagner (NetSilicon), Harry Lewis (IBM),
    Lee Farrell (Canon), Roelof Hamberg (Oce), Don Wright (Lexmark), Tom
    Hastings (Xerox)

    Agenda:
    1. Scope and purpose of the PWG Media Standardized Names standard
    2. English versus metric units
    3. Rounding error and precision of the dimensions field
    4. Desire for short names for command line applications
    5. Usable structure/syntax for extension in the future
    6. Finish Names
    7. Canon media types
    8. Stock Type Names
    9. Other fields: use of manual input tray required and printable area
    10. IBM media types
    11. IBM media sizes
    12. Media size dimension discrepancies
    13. Other comments from the mailing list

    Action items are indicated with names and are highlighted like this.

    1. Scope and purpose of the PWG Media Standardized Names standard

    After much discussion, we agreed that the purpose of the standard is for
    program to program communication of standardized names, typically in a
    protocol or data file. Even though the standard is defining names, these
    names are for program to program communication, rather than for direct
    display to human users. We also agreed that the standard is not designed
    for internal representation inside a single program (where all english and
    metric sizes might want to be converted into a single system of units).
    Such representation should be an internal implementation decision and
    outside the scope of an interchange standard, such as ours.

    One use case of our standard is for the printer driver or other client to
    display the size, type, and color that the Printer supports to the user for
    selection purposes. The supported media can be represented as attribute
    values in a PPD, GPD, or UPDF Printer Description file or returned by the
    Printer as keyword values of Printer attributes in response to a protocol
    query, such as IPP, UPnP, or other print protocol. These names should be
    localized before being displayed to an end user. Typically, a program
    performs such localization by looking up the name in the localization
    dictionary that depends on the locale (language, country, territory, system
    of measurement units) of the user. Such lookup does not require the program
    to parse the name before the lookup. Thus the localization of our names
    can be handled by a client in the same way as any other keyword or token
    that the client localizes before displaying to its user (such as any keyword
    value in IPP).

    A second use case of our standard is for a printer driver to determine the
    size of the media that the user has selected after the user has made a
    choice. The printer driver produces the appropriate PDL for the selected
    media size, type, and color.

    For both usage cases, these names have been designed to aid a program that
    is given a name that it does not recognize or is not in its localization
    data base. Such a program can still discover the size of the media for PDL
    generation purposes and can also display something meaningful to the user as
    a fallback, after some parsing and processing of the name. All of the
    localization and parsing is outside the scope of the standard. It is not
    the intent of the standard for such fallback size discovery or fallback
    presentation to be done without parsing or processing of the name. For
    example, the units may need to be converted to the internal representation
    that the printer driver uses to generate the PDL or to the user's preferred
    system of measurement units in order to be meaningfully displayed to that
    user.

    ACTION ITEM 01 (Tom, Ron): Enhance the Scope section to clarify the
    intended scope and usage of this standard.

    2. English versus metric units

    From the email discussion there was indications that some wanted every media
    size to have standardized names in both english and metric. We agreed that
    that was not the purpose of the PWG Media Standardized Names standard. So
    each media size has a customary units in either english or metric, depending
    on its usage, but not both. So far we don't know of a size that needs to
    have two names: one in english units and one in metric units in order to
    identify the media between two programs.

    There was also objection to the "na-" (North America) prefix being the only
    way to indicate English units. So we agreed that we would make a separate
    field, called "class" that starts each Media Size Self Describing Name. The
    class values will be: 'na', 'iso', 'jis', 'jpn', 'prc', (new) 'asme'. In
    order to handle some of the miscellaneous we will have an 'oe' (other
    english), and 'om' (other metric). Some of the other prefixes, such as
    'pa', and 'dai' might want to be made a class name, rather than using the
    miscellaneous class.

    ACTION ITEM 02 (Ron and Tom): create the list of classes and allocate the
    existing names to them.

    The class field will be set off from the rest of the name with the same
    separator character "." as the other fields (but see next section).

    3. Rounding error and precision of the dimensions field

    There has been email discussion showing that the current precision (1000th
    of an inch and 10th of a mm) isn't sufficient to prevent round-off error in
    converting from one to the other in the same format. We agreed that our
    standardized format didn't need to be able to represent each media in both
    english and metric for interchange purposes, so we didn't need to increase
    the precision in order to be able to represent all sizes in both units
    without round-off errors. We also agreed that any conversion from one
    system of units to another was an internal implementation matter so that the
    conversion could be to an internal representation with higher precision in
    order to avoid round off error.

    Some had thought that we were using the units in the Printer MIB. However,
    when we checked the units used in the Printer MIB we found that they were
    actually one more digit of precision for English: 10000th of an inch and two
    more digits of precision for metric: micrometers (1000th of a mm).

    So the group considered two alternatives:

    a. change the precision of the dimension field by adding one more digit to
    the inch dimensions and two more digits to the metric to agree with the
    Printer MIB units and keep the field separator character as ".". Examples:

            na.letter.85000-110000 (one more trailing zeroes)
            iso.a4.210000-297000 (two more trailing zeroes)

    b. change the dimensions field to use decimal digits and change the field
    separator to "_" (underscore) which is the only IPP keyword character left.
    Examples:

            na_letter_8.5-11
            iso_a4_210-297

    Given the agreements above about the scope and usage of the names, no one
    felt strongly that either alternative was better than the other. The a
    alternative was easier to get the number of digits wrong in implementations.
    The b alternative is more of a change from what we had, but is closer to
    HTML usage. A vote was taken which was 4 to 3 for the b alternative.

    4. Desire for short names for command line applications

    The email discussion had requested short names for command line
    applications. We agreed that such usage was outside the scope of the
    standard, but that the two column of Legacy Names and Alias (common) Names
    would help with command line size names.

    5. Usable structure/syntax for extension in the future

    We wanted to make sure that this structure for Media Size Self Describing
    Names could be extended in the future to include other fields if Media Self
    Describing Names were desired. We saw no problem with extending to other
    fields, since each field is separated by the "_" (underscore) character.
    However, such Media Self Describing Names should be the subject of other
    standards.

    6. Finish Names

    We discussed the new Finish Names field, including adding an ink-jet finish
    type, since it is a special coating for ink. Then we decided that it was
    more practical to add the finish names as more specific 'photographic' Media
    Type names. Most uses of our names, such as existing Print systems, UPnP,
    PostScript/PPD, GPD, PCL use the Media Type to represent all types of media
    and don't have separate representations for finish. Therefore, here are the
    additional Media Type Names that we agreed to add while deleting the Finish
    Type Names:

    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.

    We agreed to add a Media Type Name for ink jet and bubble jet coated paper:
    stationery-coated
    Separately cut sheets of an opaque material for use in ink jet and bubble
    jet printers

    The name: decal-transfer was proposed and we started on a Description of it
    as: for inkjet heat process, but left more wording as TBD We also realized
    that there is also a thermal-transfer Media Type.

    We agreed that in order to add more Media Type Names, we need two things:
      a. a sponsor (person or company) to request it as a needed Media Type Name
    by some implementation
      b. a description which contains more words than just the name. Such a
    description needs to help us decide whether this is really a new type or one
    that we already have.

    ACTION ITEM 03 (someone): Propose the definitions for 'decal-transfer' and
    'thermal-transfer', if you have them in an implementation and want them
    added to the standard.

    7. Canon media types

    From the email discussion and marketing information that Lee brought to the
    meeting about the Media Types proposed by Canon, we agreed to add the two
    following Media Type Names:

    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.

    8. Stock Type Names

    The email discussion had proposed that there be a new set of names added for
    the stock type, i.e., the material from which the media is made. Proposals
    had included: 'newsprint', 'index-bristol', 'recycled', 'bond'. ['recycled',
    'bond' are proposed to be added as Media Type Names by IBM - see section 10
    below].

    We agreed not to add such a new set of names, for the same reason as we
    removed the Finish Names. However, we did not discuss adding any of these
    as Media Type names. If someone want them, we need a sponsor to request it
    as a needed Media Type Name and a description which contains more words than
    just the name. ['recycled', 'bond' are proposed to be added as Media Type
    Names by IBM - see section 10 below].

    9. Other fields: use of manual input tray required and printable area

    The email discussion had requested that we add an indication of whether the
    media needed to be inserted using the Printer's manual input tray and the
    description of the printable area.

    We felt that such indication is not a property of the media per-se, but
    depends on the Printer implementation. Therefore, we would not be able to
    agree on standardized names that would apply to all implementations. Such
    information should be part of a print protocol (IPP, UPnP, etc.) or a data
    representation (UPDF) standard.

    10. IBM media types

    We looked at the IBM proposed media types from Mark VanderWiele:

    The below list of media names need to somehow be represented in the media
    name spec. This list was generated by a search of media names which were
    use in printer drivers over the last 10 years from a variety of printer
    manufactures. The names were originally provided by the various printer
    manufactures to match medias that could be used with the device. Since
    these name are used in existing drivers and in many cases match the
    documentation that came with the printer or the actual packaging on the
    media it would be best to add them with short descriptions than eliminate
    them.

    If a user buys HP PREMIUM PHOTO PAPER will they know to select GLOSSY, HIGH
    GLOSS, SATIN, OR SEMIGLOSS? We have found it is best to have the common
    names.

    [Editor's note: we didn't discuss the important comment in the previous
    paragraph. If we add some names that have a vendor's name in it as Media
    Type Names, will we get a slew of similar requests from other vendors? Some
    protocols allow the name of the media to be exchanged, such as IPP "media"
    attribute, which would allow the common name, such as
    'hp-premium-photo-paper' to be passed as a 'name' value. For other
    protocols that only have the Media Type, presumably the common name could be
    used there in order to help the user select the proper media, perhaps using
    the custom mechanism, i.e., na_custom_hp-premium-photo-paper_8.5-11.
    Remember that the printer driver doesn't have to display the "custom_" part
    of the name.]

     * MEDIA_NONE */ "None" realy means media default,
    /* MEDIA_PLAIN */ "Plain - standard white multi-purpose
    paper",

    /* MEDIA_GLOSSY */ "Media that has Glossy coating",
    /* MEDIA_SPECIAL */ "Special coated paper",
    /* MEDIA_COATED */ "Standard Coated paper",
    /* MEDIA_BACKPRINT */ "Transparent inside Window stickers -
    prints backwards"
    /* MEDIA_CLOTH */ "Used to print on Fabric",
    /* MEDIA_THICK */ "Media slighty thiker and stiffer than
    standard plain multi-purpose paper",
    /* MEDIA_HIGH_GLOSS_FILM */ "High Gloss Film",
    /* MEDIA_HIGH_RESOLUTION */ "High Resolution",
    /* MEDIA_SPECIAL_360 */ "Special 360 used for 360 resolution
    printing",
    /* MEDIA_SPECIAL_720 */ "Special 720 used for 720 resolution
    printing",
    /* MEDIA_PLAIN_ENHANCED */ "Plain Enhanced",
    /* MEDIA_IRON_ON */ "Iron-on - Media used for heat transfer
    to fabric",
    /* MEDIA_LABECA */ "Labeca",
    /* MEDIA_THERMAL */ "Thermal paper",
    /* MEDIA_CD_MASTER */ "CD-master", CD or CD label
    /* MEDIA_CARDBOARD */ "Cardboard",
    /* MEDIA_POSTCARD */ "Postcard",
    /* MEDIA_PHOTOGRAPHIC_PAPER */ "Photographic Paper",
    /* MEDIA_PHOTOGRAPHIC_LABEL */ "Photographic Label",
    /* MEDIA_PREMIUM_PAPER */ "Premium Paper",
    /* MEDIA_HP_PHOTOGRAPHIC_PAPER */ "HP Photographic Paper",
    /* MEDIA_PREPRINTED */ "Preprinted"
    /* MEDIA_LETTERHEAD */ "Letterhead"
    /* MEDIA_PREPUNCHED */ "Prepunched"
    /* MEDIA_BOND */ "Bond"
    /* MEDIA_RECYCLED */ "Recycled"
    /* MEDIA_ROUGH */ "Rough"
    /* MEDIA_VELLUM */ "Vellum"
    /* MEDIA_HEAVY */ "Heavy"
    /* MEDIA_DRILLED */ "Drilled"
    /* MEDIA_THICK_PAPER */ "Thick Paper"
    /* MEDIA_PREMIUM_HEAVYWEIGHT */ "Premium InkJet Heavyweight"
    /* MEDIA_PREMIUM_TRANSPARENCY */ "Premium Transparency"
    /* MEDIA_PREMIUM_PHOTO */ "Premium Photo"
    /* MEDIA_BROCHURE_GLOSSY */ "Brochure Glossy"
    /* MEDIA_BROCHURE_MATTE */ "Brochure Matte"
    /* MEDIA_THIN_PAPER */ "Thin Paper"
    /* MEDIA_TOUGH */ "Tough"
    /* MEDIA_SOFT_GLOSS_PAPER */ "Soft gloss paper"

    ACTION ITEM 04 (Tom, Ron): Put together a proposal for these Media Type
    Names that aren't already included. Add the ones that are included to the
    Alias (common name) column. Propose back to IBM and then include the
    consensus in the next draft.

    11. IBM media sizes

    We looked at the IBM proposed media sizes:

    Form Name: mm/100

    HALF_LETTER 13969 21597
    TABLOID 27940 43180
    UNIVERSAL 29704 43180
    WIDE 34500 27940
    LETTER_WIDE 22840 33780
    A3_WIDE 33020 48260
    A4_WIDE 22350 35560
    12_X_19 30480 48260
    15_X_11 38100 27940
    8_X_10_CARD 20320 25400
    A6_CARD 10498 14809
    CARD_148 14800 10500 Card 148
    POSTCARD 9697 14703
    D5_ENVELOPE 17600 25000
    ENVELOPE_6_1_2 16510 22000 6 1/2" Envelope
    ENVELOPE_132_220 13200 9207
    DISK_LABELS 5400 7000
    EURO_LABELS 3600 8900
    SHIPPING_LABELS 5400 10100
    STANDARD_LABELS 2800 8900
    GERMAN_LEGAL_FANFOLD 21590 33020
    PANORAMIC 21000 59400 Panoramic 210x594 mm
    PHOTO_4_6 10160 15240 Photo Paper 4x6 in
    PHOTO_100_150 10000 15000 Photo Paper 100x150 mm
    PHOTO_200_300 20000 30000 Photo Paper 200x300 mm
    SUPER_A3_B 32892 48302 Super A3/B

    Many of them look like existing sizes with metric dimensions, instead of
    English. We want to add the ones that are new sizes with their customary
    units. For example, the first one (HALF LETTER) would be added using
    English units as:

      na_half-letter_4.25-5.5

    ACTION ITEM 05 (Tom, Ron): Propose the new Media Self Describing Names that
    are truly new sizes and check with IBM to see if they are correct with the
    proper customary units, then add them to the next draft.

    12. Media size dimension discrepancies

    Also, IBM encountered multiple definitions or different definitions from the
    current table for:

    FOLIO 21590 33020 vs 21000 33000
    C7_ENVELOPE 9840 19050 vs 8100 11400
    C9_ENVELOPE 9840 22540 vs 4000 5700
    C10_ENVELOPE 10470 24130 vs 2800 4000
    FOOLSCAP 20320 33020 vs 21590 33020
    FOOLSCAP_WIDE 21590 33020

    We're [IBM] willing to go with the industry consensus but feel the
    discrepancy should be resolved.

    The ASME Y14.1-1995 Decimal Inch Drawing Sheet Size and Format standard, has
    an F size: 28 inches by 40 inches which is smaller than its E size: 34 x 44.
    But there is already an F size (f, engineering-f) from an unknown source in
    the Media standard with dimensions: 44 x 68.

    ACTION ITEM 06 (Tom, Ron): try to resolve these size discrepancies by
    referring to other standards.

    13. Other comments from the mailing list
    We reviewed other comments from the mailing list:

    The more permanent URL for the PWG process is:
    ftp://ftp.pwg.org/pub/pwg/general/pwg-process.pdf

    The permanent URL for the standard when it is approved can be added now as
    follows:
    When approved as a PWG standard, this document will be available from:
    ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf, .doc, .rtf

    Appendix A: Each of the names in this standard are represented as 'keyword'
    values in the IPP protocol, not as 'name' values. So add the phrase "keyword
    values of the" in front of each of the IPP attributes mentioned.

    Appendix A: The Media Size Self Describing Names can be represented as
    'keyword' values of the IPP/1.1 "media" attribute, so add that usage.



    This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 18:26:34 EDT