Michale wrote:
> PDL override is not even well-defined; what do you do with a PDF file
> that was formatted for a different media size? Scale it? Center it?
> Crop it? What constitutes an override???
I agree that we haven't specified what overriding media size means. I would
propse that it mean that the data is scaled (up or down), since it is the
intent of the user to print it on the media that the user specified in the
request. (But see [RFC2911] section 15.2 below.)
I haven't scanned the other Job Template and Document Template attributes,
but I think "media' is the only one that I can think that maybe isn't clear
what override would mean.
However, perhaps we could clarify what override means for all attributes, by
saying that "override means that the Printer produces the same result as if
either (1) the PDL was silent on the conflicting instruction or (2) the PDL
was produced with the same instruction as the user supplied in the IPP
request, instead of the conflicing value, depending on the instruction."
BTW,
I did go back to [RFC2911] and the definition of "pdl-override" Printer
Description attribute has a reference to section 15.2 which has exactly the
example of the media in the PDL being 'iso-a4' and the IPP "media"
attributes being 'na-letter' that you cite as unclear. Do you think it
needs further clarifcation (about "media" size and other attributes)?
Here is the [rfc2911] section 15.2 text:
15.2 Page Description Language (PDL) Override
If there is a conflict between the value of an IPP Job Template attribute
and a corresponding instruction in the document data, the value of the IPP
attribute SHOULD take precedence over the document instruction. Consider
the case where a previously formatted file of document data is sent to an
IPP Printer. In this case, if the client supplies any attributes at job
submission time, the client desires that those attributes override the
embedded instructions. Consider the case were a previously formatted
document has embedded in it commands to load 'iso-a4' media. However, the
document is passed to an end user that only has access to a printer with
'na-letter' media loaded. That end user most likely wants to submit that
document to an IPP Printer with the "media" Job Template attribute set to
'na-letter'. The job submission attribute should take precedence over the
embedded PDL instruction. However, until companies that supply document
data interpreters allow a way for external IPP attributes to take precedence
over embedded job production instructions, a Printer might not be able to
support the semantics that IPP attributes override the embedded
instructions.
The IPP model accounts for this situation by introducing a
"pdl-override-supported" attribute that describes the Printer objects
capabilities to override instructions embedded in the PDL data stream. The
value of the "pdl-override-supported" attribute is configured by means
outside the scope of this IPP/1.1 document.
This REQUIRED Printer attribute takes on the following values:
- 'attempted': This value indicates that the Printer object attempts to make
the IPP attribute values take precedence over embedded instructions in the
document data, however there is no guarantee.
- 'not-attempted': This value indicates that the Printer object makes no
attempt to make the IPP attribute values take precedence over embedded
instructions in the document data.
At job processing time, an implementation that supports the value of
'attempted' might do one of several different actions:
1) Generate an output device specific command sequence to realize the
feature represented by the IPP attribute value.
2) Parse the document data itself and replace the conflicting embedded
instruction with a new embedded instruction that matches the intent of the
IPP attribute value.
3) Indicate to the Printer that external supplied attributes take precedence
over embedded instructions and then pass the external IPP attribute values
to the document data interpreter.
4) Anything else that allows for the semantics that IPP attributes override
embedded document data instructions.
Since 'attempted' does not offer any type of guarantee, even though a given
Printer object might not do a very "good" job of attempting to ensure that
IPP attributes take a higher precedence over instructions embedded in the
document data, it would still be a conforming implementation.
At job processing time, an implementation that supports the value of
'not-attempted' might do one of the following actions:
1) Simply pre-pend the document data with the PDL instruction that
corresponds to the client-supplied PDL attribute, such that if the document
data also has the same PDL instruction, it will override what the Printer
object pre-pended. In other words, this implementation is using the same
implementation semantics for the client-supplied IPP attributes as for the
Printer object defaults.
2) Parse the document data and replace the conflicting embedded instruction
with a new embedded instruction that approximates, but does not match, the
semantic intent of the IPP attribute value.
Tom
P.S. I'm only replying to the IPP DL as requested by some members.
-----Original Message-----
From: Mike Sweet [mailto:mike@easysw.com]
Sent: Saturday, April 19, 2003 20:14
To: McDonald, Ira
Cc: 'Harry Lewis'; Hastings, Tom N; ipp@pwg.org; ps@pwg.org; sm@pwg.org
Subject: Re: SM> Re: IPP> 4 significant proposed increases in
conformance requirements for the IPP Document object spec
McDonald, Ira wrote:
> ...
> 2) I agree that PDL override is hard to implement (in _some_ PDLs), but
> what Tom and I have proposed is to disambiguate _which_ attributes
> (if any) can be guaranteed to successfully override the PDL. Seems
> to me like a good clarity enhancement to IPP.
PDL override is not even well-defined; what do you do with a PDF file
that was formatted for a different media size? Scale it? Center it?
Crop it? What constitutes an override???
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 03:06:42 EDT