At 15:28 01/09/1998 PST, Harry Lewis wrote:
>Tom,
>>>It is overridden by the PDL, as long as the PDL not 'text/plain' or
>>any document that has the orientation instructions embedded in the >PDL.
>>I think you mean ... any document that DOESN'T have the orientation
>instruction in the PDL... right??
Yes.
>>Maybe I haven't made myself clear that what seems out of place to me is the
>opposition of the following...
>>Section 2.2, pg. 15
>"job-templet" attributes... include job processing instructions...
intended to
>override... embedded... document data.
>>AND
>>4.2.10... the definition of Orientation (a job-templet attribute) which
clearly
>calls out PDL override.
>> An object or attribute who's DEFINITION says the PDL will override does not
>belong in this category, in my opinion! (Or the category is ill defined or
>described).
>>In retrospect, just changing the name to include "plain-text" is probably not
>the best solution since the problem pertains to
>ANY form of data sent to the printer which is not encapsulated in a PDL (ex.
>image).
I agree with you.
The "orientation" attribute really has the semantics of an
IPP "orientation-default" attribute because it only takes effect
if the document data does not have an instruction embedded in it.
Currently client don't submit "xxx-default" attributes in IPP, though we
had about 9 such attributes in DPA that had the semantics of only taking
effect if the document content had no corresponding instruction.
Those 9 DPA attributes are (in DPA we put "default" first):
default-medium
default-input-tray
default-font
default-resources (electronic form, bit map, etc.
that is in the printer library)
default-character-set
default-character-mapping
default-printer-resolution
In fact, the IPP "document-natural-language" operation attribute
is similar to the IPP "orientation" (being renamed to
"orientation-requested") job template attribute, in that
it only applies to documents that need it.
So another approach would be to move the "orientation-requested" attribute
from the Job Template group to become an operation attribute for
Print-Job, Validate-Job, Print-URI, Send-Document, and Send-URI, just
like we have: "document-format" and "compression".
Operation attributes are a grab bag of attributes, while Job Template
attributes have more regular semantics as you point out.
Tom
>>Harry Lewis - IBM Printing Systems
>>>>>hastings at cp10.es.xerox.coM on 01/09/98 11:06:27 AM
>Please respond to hastings at cp10.es.xerox.coM @ internet
>To: ipp at pwg.org @ internet, Harry Lewis/Boulder/IBM at ibmus>cc:
>Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value
>>>At 07:37 01/09/1998 PST, Harry Lewis wrote:
>>I tried to send this yesterday but there was a problem...
>>>>Harry Lewis - IBM Printing Systems
>>>>>>---------------------- Forwarded by Harry Lewis/Boulder/IBM on 01/09/98
>08:22 AM
>> ---------------------------
>>>>>>Harry Lewis
>>01/08/98 04:43 PM
>>To: ipp at pwg.org @ internet
>>cc:
>>From: Harry Lewis/Boulder/IBM @ IBMUS
>>Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value
>>>>Since job-template attributes are intended to override embedded print stream
>>instructions, I'm confused by 4.2.10 orientation-requested (type2 enum)
>which,
>>by its definition, indicates the opposite (this attribute WILL be
>overridden by
>>the PDL as a matter of course, if I understand correctly).
>>It is overriden by the PDL, as long as the PDL not 'text/plain' or
>any document that has the orientation instructions embedded in the PDL.
>>>>>If we're just trying to address "plain-text" with this attribute, then
>maybe it
>>should be called "plain-text-default-orientation"?
>>It maybe good to include "plain-text" in the name. However, I don't
>think we need to include "default", since for plain text it isn't the
>default, its what the client is asking the Printer to do and an IPP
>printer that supports "plain-text-orientation" MUST be able to handle
>whatever values the "plain-text-orientation-supported" attribute contains.
>>Alternatively, we haven't (yet) considered the client being able to
>submit "xxx-default" attributes. In this case, if the attribute
>were "orientation-default" that the client supplies, then any PDL
>that embeds orientation would override and any PDL that doesn't
>contain an orientation, such as 'text/plain', would be affected by
>the "orientation-default" attribute.
>>>>>Otherwise, this particular attribute appears to go against the grain with
>>respect to the intent of job-template attributes. I think it is unique in
>this
>>sense which could be why we are struggling with the definition.
>>Good observation. I agree.
>>>>>Harry Lewis - IBM Printing Systems
>>>>>>>>>>ipp-owner at pwg.org on 01/08/98 10:04:56 AM
>>Please respond to ipp-owner at pwg.org @ internet
>>To: hastings at cp10.es.xerox.com @ internet, ipp at pwg.org @ internet
>>cc:
>>Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value
>>>>>>I suggest the following wording for the paragraphs 4.2.10 that Tom wrote
>>and I enclose below:
>>>>My wording:
>>-----------------------------------------------
>>For documents whose document-format does not explicitly specify the
>>orientation (e.g. text/plain), this attribute specifies the
>>client-requested orientation of the content of the print-stream pages
>>when they are printed. For documents whose document-format does explicitly
>>specify the orientation (e.g. PostScript), this attribute has no meaning --
>>it neither alters the orientation nor specifies the existing orientation.
>>-----------------------------------------------
>>Tom's wording:
>>>>> From hastings at cp10.es.xerox.com Wed Jan 7 18:21:58 1998
>>> Proposed new text:
>>>>>> 4.2.10 orientation-requested (type2 enum)
>>>>>> This attribute specifies the orientation of the content of the
print-stream
>>> 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 (such as 'text/plain') 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 when the IPP Printer performs the formatting.
>>>>>>>>>>>>>>>>>>>>>>>>>