So to summarize:
1. stapling - yes here we envision the client proving the full set of stapling options to the user. Whether they in fact want top left or top right staples (is this naïve? Perhaps the UI should just choose instead but I'd rather be open here vs restrictive if we don't have full confidence in use cases).
2. As far as "landscape control" I'm not sure what is meant - is the suggestion to offer both landscape and reverse-landscape to the user? I see no current dialogs doing this but rather them currently translating a Landscape dialog request into landscape vs reverse-landscape
3. Concern here is whether client choice of Landscape orientation impacts printer ability to do transformations such as inserting staples, bindings, etc. I just want to make sure that what we decide is congruent to what printer optional components require as far as stapling positions, etc. I'm more soliciting information here so we can make informed decisions, rather than critiquing current specs. If client heuristics are what's best then maybe let's make that more solidified in terms of behavior.
-----Original Message-----
From: Michael Sweet <msweet at msweet.org>
Sent: Thursday, June 26, 2025 11:12 AM
To: Michael Ziller <mziller at microsoft.com>
Cc: PWG IPP Workgroup <ipp at pwg.org>
Subject: Re: [EXTERNAL] [IPP] Specifying landscape orientation for PWG-Raster
Michael,
> On Jun 26, 2025, at 1:44 PM, Michael Ziller <mziller at microsoft.com> wrote:
>> I see OK, that's more in line with what I thought - that media-source-properties was only describing media source properties and not desired client behavior for rotations. However, the latter is what the "other attribute" conveyed to the client.
Actually, the "other attribute" was just conveying the PPD LandscapeOrientation value, which assumed that every input source of a PostScript printer used the same orientation for landscape content media (and the printer didn't try to auto-rotate the content).
What we ended up adding for IPP didn't try to reproduce the PPD semantics but rather, "how can we communicate to the Client how a Printer wants its content prepared?" Certainly tangentially similar but with a bigger scope since we wanted to fully describe the media for a given source.
> If it's insufficient, then I think as far as spec work just saying the client should do whatever appropriate is less prescriptive. Won't we run into issues here if client1 decides to rotate CW and client2 decides to rotate CCW for a given printer?
For generic media, no. For envelopes and letterhead, it is certainly possible but that is where we are providing a specific orientation-requested value to the Client.
> I suppose the impact may just be that e.g. client1 shows less stapling options compared to client2 since it chose a rotation which doesn't match the finishings-supported as well for Landscape prints.
Most print UI for finishings either has limited choices ("staple") and the Client chooses the best corner for the user, or the UI lists every staple option and forces the user to make the choice. Each has their place...
That said, if print UI just has a single checkbox for "staple", then is may also just have a single "portrait/landscape" control and the Client can choose which kind of landscape to use to put that staple in the right corner.
> Maybe I'm missing some considerations here. Just want to be sure that leaving this up to the client doesn't have concerns as far as specification. Mopria is looking to solidify PWG-R rotation behavior and if 'client decides' is the best strategy then that would be good to outline. But I'd first like to get further feedback on whether that will have any future drawbacks (since this may have firmware implications). I'll attend next PWG meeting and have encouraged interested Mopria members to as well to discuss further.
Most of the time the direction of rotation is less important than the fact that it is rotated to landscape. Users want consistency, of course, but I'd hope that Client software can make a consistent choice based on what the Printer reports for the media and for any finishing options that might be applied.
________________________
Michael Sweet