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