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

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

Hastings, Tom N hastings at cp10.es.xerox.com
Fri Apr 27 18:25:03 EDT 2001


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.





More information about the Ipp mailing list