Subject: IPP>MOD - new attributes

From: Roger K Debry <[email-masked]>
Date: Fri, 15 Aug 1997 16:59:43 -0400

At the last PWG meeting, I agreed to write up proposed wording for several
changes we had asked for in the model document.
Here are some of these changes for your review.  I am assuming that if there is
no comment, these will go into the next version of
the model document as written here ...

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).

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.

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.

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.

Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080
er, some do

---

From: JK Martin <[email-masked]>
Date: Sat, 16 Aug 1997 13:17:10 -0400 (EDT)

Nice write-up, Roger.  How about some examples for each attribute,
particularly for boundary or other strange situations?

	...jay

----- Begin Included Message -----

>From [email-masked] Fri Aug 15 17:07 EDT 1997
From: Roger K Debry <[email-masked]>
To: <[email-masked]>
Subject: IPP>MOD - new attributes
Date: Fri, 15 Aug 1997 16:59:43 -0400

At the last PWG meeting, I agreed to write up proposed wording for
several changes we had asked for in the model document.  Here are some
of these changes for your review.  I am assuming that if there is no
comment, these will go into the next version of the model document as
written here ...

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.

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.

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.

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:

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.

Roger K deBry

----- End Included Message -----

---

From: Roger K Debry <[email-masked]>
Date: Mon, 18 Aug 1997 14:47:23 -0400

<RKD> Examples follow ...

 ...jay

<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

<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).

<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

<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

----- End Included Message -----