IPP> MOD - Definition for 'reverse-portrait' enum value

IPP> MOD - Definition for 'reverse-portrait' enum value

Tom Hastings hastings at cp10.es.xerox.com
Fri Jan 9 20:45:03 EST 1998


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



More information about the Ipp mailing list