Subject: Re: IPP> MOD - Definition for 'reverse-portrait' enum value

From: Harry Lewis <[email-masked]>
Date: Fri, 9 Jan 1998 18:28:12 -0500

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

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

Harry Lewis - IBM Printing Systems

[email-masked] on 01/09/98 11:06:27 AM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet, Harry Lewis/Boulder/IBM@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: [email-masked] @ 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
>
>
>
>
>[email-masked] on 01/08/98 10:04:56 AM
>Please respond to [email-masked] @ internet
>To: [email-masked] @ internet, [email-masked] @ 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 [email-masked] 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.
>>
>
>
>
>
>
>
>
>
>

---

From: Tom Hastings <[email-masked]>
Date: Fri, 9 Jan 1998 17:45:03 PST

>instruction in the PDL... right??

Yes.

>ANY form of data sent to the printer which is not encapsulated in a PDL (ex.

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