Nice write-up, Roger. How about some examples for each attribute,
particularly for boundary or other strange situations?
<RKD> Examples follow ...
...jay
4.2.3 copies (integer 1:2**31-1))
This attribute specifies the number of copies to be printed. On many
devices the supported number of collated copies will be limited by the
number of physical output bins on the device, and may be different
from the number of uncollated copies which can be supported. Therefore
the copies-supported attribute specifies a set of ranges; the first
defines the supported range of values for uncollated copies, and the
second the supported range of values for collated printing. The set of
default values for copies specify the default number of uncollated
copies followed by the default number of collated copies.
The effect of this attribute is controlled by the
"multiple-documents-handling" attribute (section 4.2.6).
<RKD> Example 1: Printer does not support collating, administrator has
<RKD> set max number of copies to 5, and the default to one copy.
<RKD> copies-supported = 1:5, 0:0
<RKD> copies (Printer) = 1:0
<RKD> Example 2: Printer print collated or uncollated copies, but has only
<RKD> 10 collating bins, so the max number of collated copies is 10. The
<RKD> administrator has set the maximum number of copies to 10 for both
<RKD> collated or uncollated copies. The default has been set to one for
<RKD> both cases.
<RKD> copies-supported = 1:10, 1:10
<RKD> copies (Printer) = 1:1
<RKD> Example 3: The printer does not support multiple copies.
<RKD> copies-supported = 1:1, 0:0
<RKD> copies (Printer) = 1:0
4.2.19 page-range (1setOf integer)
This attribute specifies the pages of a document which are to be
printed. In most cases, the exact pages to be printed will be generated
by a device driver and this attribute would not be required. However,
when printing an archived document which has already been formatted,
the end user may elect to print just a subset of the pages contained in
the document. In this case, if page-range = n.m is specified, the first
page to be printed will be page n. All subsequent pages of the document
will be printed through and including page m.
Page-range supported is a boolean value indicating whether or not the
printer is capable of supporting the printing of page ranges. This
capability may differ from one PDL to another. The page-range default
value is always zero (0) and indicates that all pages of the document
will be printed if a page-range is not specified.
<RKD> Example 1: Printer does not support printing of page ranges.
<RKD> page-range-supported = false
<RKD> page-range (Printer) = 0
<RKD> if job is submitted with a page-range attribute, it is rejected
<RKD> unless fidelity is set to false.
<RKD> Example 2: Printer supports printing page ranges for PostScript
<RKD> files only. Client submits a job and asks for pages 1 to 5.
<RKD> page-range-supported = true (when document-format = PostScript)
<RKD> otherwise page-range-supported = false.
<RKD> page-range (Printer) = 0
<RKD> page-range (Job) = 1:5
<RKD> Example 3: as above but client wants to print the entire document.
<RKD> page-range-job = 0 (or not supplied in request).
4.2.20 orientation (type2 enum)
This attribute specifies the orientation of the content on the output
pages to be printed. In most cases, the orientation of the content is
specified within the document format generated by the device driver at
print time. However, some document formats do not support the notion
of page orientation and it is possible to bind the orientation after
the document content has been generated. This attribute provides an
end user with the means to specify orientation for such documents.
Standard values are:
'Portrait" (1): The content will be printed across the short edge of
the media. 'Landscape (2): The content will be printed across the long
edge of the media.
<RKD> I've added an enum (0) which means printer does not support
<RKD> orientation for document-content in this PDL, i.e. you get
<RKD> whatever is established inside the document content itself.
<RKD> Example 1: Printer supports setting landscape or portrait for text
<RKD> files only. The default is portrait. User selects Landscape for a
<RKD> text file.
<RKD> orientation-supported = 1,2 (for document-content = text only.
<RKD> Otherwise orientation = 0)
<RKD> orientation (Printer) = 1 (for document-content = text only)
<RKD> orientation (Job) = 2
<RKD> Example 2: Printer does not support this function for any PDL
<RKD> User attempts to set orientation when job is submitted.
<RKD> orientation-supported = not supplied
<RKD> orientation (Printer) not supplied
<RKD> orientation (Job) = 1
<RKD> If fidelity = true, job is rejected with unsupported-attribute
Media available attribute:
I propose that the current media attribute have the connotation of
"media-ready". That is, the media- supported attribute represents media
actually ready to print To support production environments where a
printer operator is normally available to load special papers, the
following additional attribute is proposed:
4.2.21 Media-available (1setOf type4 keyword)
In many production printing environments some media, such as special
pre-printed forms, may be available to be loaded on the printer by an
operator when requested. Under normal conditions, these would not be
reflected in the values of the media-supported attribute, since they
are meant to indicate only what is normally loaded on the printer and
ready to use. However, it is useful for an end user to know what media
are available to be loaded so that the correct media name can be
specified in the 'media' attribute. This allows jobs which require
special media to be loaded to be queued and batched together to be
printed once the correct media is loaded. Thus the attribute not only
provides help in scheduling work but as input to an operator on how to
set up the printer for a particular batch of jobs.
Since the end-user actually specifies the media to be loaded in the
'media' attribute, and the default indicates a ready media, there are
no equivalent job and template attributes.
<RKD> Printer has two input trays which normally contain letter and
<RKD> legal size paper. However, the operator has the ability to load
<RKD> special pre-printed forms when required. If the paper is not
<RKD> loaded, the jobs will be held until the operator loads one of
<RKD> them and sets (by some method outside the scope of IPP) Media
<RKD> equal to the loaded form. For this example, let the forms that
<RKD> can be loaded have enterprise defined names called "letterhead"
<RKD> and "internal-memo". The default is letter.
<RKD> Initially, media-supported = na-letter-white, na-legal-white
<RKD> media (Printer) = na-letter-white
<RKD> media-available = letterhead, internal-memo
<RKD> media (Job) = letterhead
<RKD> Job is held until operator loads letterhead paper in the letter
<RKD> sized tray. media-supported changes to letterhead, na-legal-white.
<RKD> All jobs held pending loading of this media are now scheduled
<RKD> and run. Note, if media-available were not a valid IPP attribute,
<RKD> (a) there would be no way to signal that the paper should be loaded
<RKD> (b) the job would get rejected for an invalid attribute value
<RKD> (c) there would be no way to hold the job until paper was loaded.
Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
er, some do
----- End Included Message -----