From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed May 09 2001 - 20:18:11 EDT
I've down loaded the Strawman Requirements for the Media Size Self
Describing Names that Ron and I put together:
ftp://ftp.pwg.org/pub/pwg/media-sizes/media-size-requirements-010509.pdf
ftp://ftp.pwg.org/pub/pwg/media-sizes/media-size-requirements-010509.doc
I've also copied them into this mail message as plain text, so you can read
them either way.
The call info is:
Monday, May 14, 1-2 PM PDT (4-5 PM EST)
Phone: (415) 228-4883, passcode: 74584#
(Xerox folks: 8*534-6413) [confirmation code: 5954723]
AGENDA:
A. Are the Strawman Requirements agreed (see below or down-loaded)?
Please send comments (to the IPP DL, not PWG-ANNOUNCE) before the telecon.
B. Can we resolve the 3 issues included in it?
Please send comments (to the IPP DL, not PWG-ANNOUNCE) before the telecon.
C. Can we resolve the 3 outstanding issues in D0.8?
from Ron's D0.8 announcement of D0.8 draft which is available at:
ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-08.pdf (.doc or .rtf)
ISSUE 04. Should the format of the Media Size Self Describing Name include
the
units? The meeting in Portland agreed not to include the units but the
recent teleconference concluded that specifying the units was preferred.
The Portland agreement uses the "class" name to provide an implied units.
(See requirement #5)
ISSUE 05: Should the short dimension be separated from the long dimension by
a
hyphen ("-") or an "x"?
(See requirement #14)
ISSUE 06. How should the "class" (or "prefix") portion of those Self
Describing
Names that are not specified by a sanctioned standards body be defined? I
have added "om" to those names that did not have a clearly defined "class".
There are three in Table 6 and five in Table 7. Also, Table 3 has an entry
"na-asme-..." that could be justified with a class of "asme-" instead of
"na".
(See requirement # 9 and ISSUE 01 below)
Thanks,
Tom and Ron
Strawman Requirements for
Media Size Self Describing Names
in
the PWG Media Standardized Names standard
>From Tom Hastings, Ron Bergman
File: media-size-requirements-010509.doc
May 9, 2001
The specification for the Media Size Self Describing Names in the PWG Media
Standardized Names standard must meet the following requirements and
non-requirements in order of decreasing importance and priority:
1. Be optimized for program to program communication of media
sizes. Examples include the following Sender to Recipient Software
scenarios: (1) from a Printer to Client Software, (2) from Client Software
to a Printer, and (3) from a printer data description file to Client
Software.
2. The syntax is not intended for use as internal
representation within a program. (Programs will typically want to convert
media sizes into a single system of internal units that is usually scaled
integer values.)
3. Cover cut sheet media sizes. Roll size media is outside the
scope of the standard.
4. Cover media sizes that are normally measured in English
units and the media sizes that are normally measured in metric units. Only
include the each name in its native units.
5. In the future, if some other units besides English and
metric units need to be added to the standard (for new media sizes), be able
to do so in a way that Recipient Software can detect that the units are
neither English nor metric, if they need to determine the actual size.
[This requirement was added at the Portland meeting.] Since Recipient
Software code will need to be changed in order to handle such new units, the
units should be baked into the ABNF and a new major revision of the standard
produced if new units are introduced.
6. Be self describing, (1) so that Recipient Software that
receives an unrecognized name, can still determine the intended size and (2)
so that simple Recipient Software may be implemented without needing an
internal media size table of recognized media sizes. Consequence: Media
Size Self Describing Names have both a Media Size Name part and a Media
Dimensions part.
7. Do not include two Media Size Self Describing Names that
have the same Media Size Name. Indicate any such duplicate names as alias
(common) name or Legacy Names.
8. Do not include two Media Size Self Describing Names that are
the same size, i.e., have the same Media Dimensions value or are the same
size in both English and metric units. For example, don't have two size
names, where both Media Dimensions parts indicate 8.5 x 11 inches or one
part indicates 8.5 x 11 inches and the other indicates 115.9 x 279.4 mm.
The name is only standardized in the units of its normal usage.
9. Be able to disambiguate between two names that are otherwise
the same, by the usual method to indicate the name space (naming authority,
standards body, country, region of usage, or area of application), i.e., a
high order part of the name. For example, ISO B4 and JIS B4 are different
sizes. Also the F size and the ASME F size are different.
ISSUE 01: Ok for some standard names not to have a high
order part that indicates some name space, i.e., can we eliminate the "om-"
and "oe-" prefixes for other metric and other english?
10. Be able to register additional Media Size Self Describing
Names after the standard is approved. These additional names should not
require any code change to programs that can handle the names in the first
version of the approved standard. Be able to introduce new high order parts
for new names, as the need arises, to identify these registered names.
Implication: Since Recipient Software will not need to be changed, don't
bake in the high order parts of the names into the ABNF, but just make them
part of the Media Name part.
11. Standardize Media Size Self Describing Names, along with
their Media Size Names that can be used in other existing standards, such as
Appendix B "Media Sizes Names" of the Printer MIB, keyword values of the
IPP/1.1 "media" Job Template attribute, and future standards, such as the
MediaSize parameter in the UPnP Basic Print Template.
12. Design the syntax to facilitate Recipient Software parsing
the Media Size Self Describing Name into a separate Media Size Name part and
a separate Media Dimensions part, in order to recognize either part.
Recipient Software need only do a straight string comparison to see if it
recognizes the Media Dimensions part; it need not perform any unit
conversion, rounding, or closest size match. Implication: the numbers in
the Media Dimensions part need to have a canonical representation.
13. Design the syntax to make it easy for Client Software to
parse the Media Size Self Describing Name into a separate Media Name part
and a separate Media Dimensions part, in order for the Client Software to
either (1) localize the Media Size Name part and/or (2) to convert the
Dimensions part into the user's preferred system of units.
14. Design the syntax to make it easy for Client Software to
present the Media Size Self Describing Name to users in its entirety, either
because it is an unrecognized name or because the Client Software doesn't
want to have an internal media size table. Such a display is called a
Fallback Display. Implication: the syntax should be human readable for most
human languages.
15. Restrict the names to use the characters for IPP keywords
(a-z, 0-9, -, ., _, and no spaces), so that the names can be used as keyword
values of the IPP/1.1 "media" Job Template attribute. Furthermore, deployed
IPP/1.1 Client Software can use their normal Fallback procedure for display
of unrecognized keywords to users, namely, just present the entire keyword
as the value.
16. It is outside the scope of the standard to specify which
part takes precedence when Recipient Software receives a corrupted name,
where the Media Name part doesn't agree with the Media Dimensions part,
according to the names currently in the standard (or subsequently
registered), or whether the Recipient Software MUST/SHOULD/MAY consider the
request an error. Note: if the name starts with 'custom-', then the
Recipient Software knows it isn't a standardized name. For example, if
'na-letter_9x13in' is received, does the Recipient Software assume that it
is 8.5 x 11 inches or 9 x 13 inches or an error?
ISSUE 02: Ok for the standard to say that it is
IMPLEMENTATION DEPENDENT what Recipient Software does when it receives a
Media Size Self Describing Name which has a Media Size Name part that
disagrees with the Media Dimensions part? It can use the Media Size Name
part, the Media Dimensions part, or treat the name as an error.
17. Provide a special syntax for a vendor, system administrator,
or user to define a Custom Media Size Self Describing Name to send to
Recipient Software, i.e., a name whose size is not in the standard (or has
not been registered) and to optionally include a Media Name part as well.
Allow such a Custom Size Name to be used anywhere a Media Size Self
Describing Name can be used.
ISSUE 03: Why does this have to be a special syntax, i.e.,
Media Size Name starts with "custom-"? Why can't a vendor, system
administrator, or user invent a Media Size Self Describing Name and use it
without the "custom-" prefix? What happens when a later version of Client
Software sends newly registered media size names to an older Printer that
only recognizes the names in our 1.0 standard? Does the client have to
query the printer and use the "custom-" prefix for such a registered name,
if it isn't in the Printer's supported list?
18. Provide a distinguished Custom Media Size Self Describing
Name that indicates the smallest custom dimensions supported and another one
to indicate the largest custom dimensions supported.
Alternatives to meet the above requirements
At the Wednesday, May 2, telecon, we considered the following five
alternatives:
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 reached an 8-0 consensus for alternative (a). At the earlier Portland
meeting, Tuesday, April 24, we only considered alternatives b and c and had
a 4-3 split with no strong feelings between either of the two.
This archive was generated by hypermail 2.1.4 : Thu Apr 16 2009 - 10:55:40 EDT