Tom,
I am certainly not the absolute IPP expert.
But I know exactly what drivers expect to get out of bidi communication.
1. A driver can convert a unique IPP media size keyword (that is close to
Michael Sweet's proposal) to an operating system specific keyword. But then
it needs a keyword for every size, not only the standard size - also the
custom sizes. In this case there is typically a range reserved for custom
size keywords.
2. A driver can convert two unique IPP media size dimension values to an
operating system specific keyword. In that case the driver would do some
rounding and truncating.
3. A driver has tremendous problems converting a localized IPP string to an
operating system specific keyword for media sizes. This would be a
nightmare.
A driver certainly appreciates a string for any size and can handle
localized strings. But this should never replace unique technical keywords
like in method 1 or 2.
UPDF definitely will have one unique technical keyword per media size. The
values for width and height will work as attributes of media size.
In case IPP will send width and height values only, these (with some coding
effort) will work to identify a certain size. From then on the UPDF may
provide its own values, which could be slightly different from the sent IPP
values, as I think standard sizes should be announced consistently.
The UPDF media size identifier could, but need not be the operating system
identifier already. UPDF is considered to be universal and operating systems
may expect different identifiers for the same size. So the UPDF is not
necessarily the value to be announced to the operating system.
When the operating system recognizes a certain size, it also can reject the
values the driver is announcing for this size - for the same reasons as
explained above: the OS may provide its own list of standard sizes with
dimension values. Once a size is identified, the values may be taken from
that OS list.
I hope I could make the different layers involved from the device to the OS
more transparent.
A localized string for a media size is an appreciated information for a
driver, but can never work as an identifier. It can never replace technical
identifiers. Those strings could be different from printer to printer and
from language to language.
Norbert
-----Original Message-----
From: Hastings, Tom N <hastings at cp10.es.xerox.com>
To: ipp (E-mail) <ipp at pwg.org>
Date: Monday, September 18, 2000 7:36 PM
Subject: IPP> PPE - Issue about adding "media-size" by name in addition to
"media-size" by dimensions
>Last week, while reviewing the Production Printing Extension spec at the
IPP
>WG meeting, we agreed to allow the sender (client or printer) to specify
>media size either by dimensions or by name, instead of only by dimensions.
>However, I want to push back on that decision.
>> ISSUE: We agreed to add "media-size" (type3 keyword | name)
>to allow the sender (client or printer) to specify media size either by
>dimensions or by name, instead of only by dimensions. However, the
>description of the existing "media-size" (collection) member attribute
>clearly indicates that the client localizes the size numbers to include the
>size name appropriate for the locale of the user.
>> I checked with several existing clients: the user either
>selects from a list that has both the names with dimensions in parentheses,
>or has names and the driver echoes back the dimensions when the user
selects
>a name, or the user selects an arbitrary pair of numbers which has no name.
>All this functionality can be accomplished by a single member attribute in
>the protocol, namely, "media-size" (collection), where collection contains
>the two numbers.
>> OK to go back to the original specification with just
>"media-size" (collection) in which only the dimensions in hundredths of a
>millimeter (equivalent to 1/2540 th of an inch resolution)?
>>>Here is the complete description of the "media-size" (collection) member
>attribute before last week's meeting (that I want to go back to before last
>call on the Production Printing Extensions):
>> 3.8.10 media-size (collection)
>> The "media-size" member attribute is a collection that
>explicitly specifies the numerical media width and height dimensions.
>> It is RECOMMENDED that a client localize the collection
>values to the size names that users are familiar with, such as 'letter' and
>'A4', possibly also including the exact dimensions as well (and in the
units
>appropriate for the user's locale). If a client does not recognize a pair
>of numbers as a named size, it can simply display the two numbers instead.
>Thus the pair of size dimensions serve the same function as keyword values,
>except that the client has an obvious fallback display for an unrecognized
>pair, namely, the actual dimension numbers.
>> The "media-size" collection member attributes are:
>>Table 8 - "media-size" member attributes
>Attribute name attribute syntax request Printer Support
>x-dimension integer (0:MAX) MUST MUST
>y-dimension integer (0:MAX) MUST MUST
>>> 1.1.1.1 x-dimension (integer(0:MAX))
>> Indicates the size of the media in
>hundredths of a millimeter along the bottom edge of the media. See section
>2.3 regarding the coordinate system. This unit is equivalent to 1/2540 th
>of an inch resolution.
>> 1.1.1.2 y-dimension (integer(0:MAX))
>> Indicates the size of the media in
>hundredths of a millimeter along the left edge of the media. See section
>2.3 regarding the coordinate system. This is equivalent to 1/2540 th of an
>inch resolution.
>> 1.1.1.3 media-size-supported (1setOf
>collection)
>> Indicates the sizes supported by the
>Printer. A requested media size dimension matches a supported media
>dimension if it is within an implementation-defined tolerance. For
example,
>PostScript [redbook] specifies a tolerance of 5 points (5/72 of an inch =
>1.7 mm) of a supported dimension, i.e., within 176 units of the value of
the
>dimension.
>> The "media-size-supported " collection
>member attributes are:
>>Table 9 - "media-size-coll-supported" member attributes
>Attribute name attribute syntax request Printer Support
>x-dimension integer (1:MAX) | rangeOfInteger (1:MAX) MUST MUST
>>y-dimension integer (1:MAX) | rangeOfInteger (1:MAX) MUST MUST
>>>> 1.1.1.3.1 x-dimension (integer(1:MAX)
>| rangeOfInteger(1:MAX))
>> Indicates the size of the media in
>hundredths of a millimeter along the bottom edge of the media. The
>rangeOfInteger attribute syntax accommodated variable size implementations,
>including web printers. See section 2.3 regarding the coordinate system.
>This is equivalent to 1/2540 th of an inch resolution.
>> 1.1.1.3.2 y-dimension (integer(1:MAX)
>| rangeOfInteger(1:MAX))
>> Indicates the size of the media in
>hundredths of a millimeter along the left edge of the media. The
>rangeOfInteger attribute syntax accommodated variable size implementations,
>including web printers. See section 2.3 regarding the coordinate system.
>This is equivalent to 1/2540 th of an inch resolution.
>>>-------------- next part --------------
A non-text attachment was scrubbed...
Name: Norbert Schade.vcf
Type: text/x-vcard
Size: 447 bytes
Desc: not available
Url : http://www.pwg.org/archives/ipp/attachments/20000919/c7d094bb/NorbertSchade-0001.vcf