Add support for orientation option

[jameshalsall]

This embeds the Orientation value in the PWG header, but it seemingly has no effect (at least on the Epson printer I've specified). However, it is definitely being embedded so this could be a quirk with the printer.

[attah]

I'm not so surprised this has no effect. Asking raster printers to transform the page seems rather orthogonal with that they may require the client to help transform duplex backsides. As i understand it, this is to not need to have the entire uncompressed raster in RAM. Needing to do rotation for you would negate that optimization. (And i see several printers that need said help, but still supposedly support other orientations. Even including needing backsides rotated for it but claiming support for reverse portrait in IPP).

So, similar to attributes related to backside-transform, it could well be one of those attributes where you describe what you have done to the document data, rather than what you want the printer to do with it.

The standard (cs-ippraster) is not very clear on what this is though. RFC 8011 says the corresponding IPP attribute specifically has nothing to do with what you send to the printer, just how you want it printed. But i guess that could just mean that it, like copies, is one of those things to "move" from IPP to the PWG raster header. Ipptransform doesn't seem to do anything with it outside of number-up. Maybe it's a dead setting?

But i'm curious, why would you want your document to come out long-side-first? I know sometimes this is done, though i can't help but feel it is just a waste of maximum paper size that can be used.

I also see you still keep your now-obsolete commits - if there is something wrong with what i did, do tell me.

[jameshalsall]

Thanks for commenting @attah that's really helpful.

But i'm curious, why would you want your document to come out long-side-first? I know sometimes this is done, though i can't help but feel it is just a waste of maximum paper size that can be used.

We have preprinted media and have found that flipping on the long edge is required in some cases to align the printed front with the back.

I also see you still keep your now-obsolete commits - if there is something wrong with what i did, do tell me.

No not at all. We plan on switching back to the upstream as soon as we schedule some updates on our device fleet 👍🏻. Our fork has some code to maintain support with an older poppler version which can become a pain when bringing in upstream changes that use newer poppler features.

[jameshalsall]

Also we have found this Orientation option has no effect on the printed result. However it is mentioned in this document, alas maybe it is a dead setting though like you say?

[attah]

We have preprinted media and have found that flipping on the long edge is required in some cases to align the printed front with the back.

As in that the printer does a better job with alignment if pages are fed like this?
Because i don't see that this would necessarily change how the sides are printed relative to eachother.
It is not just --tumble that you are after? (Or missed accounting for pwg-raster-document-sheet-back?)

No not at all. We plan on switching back to the upstream as soon as we schedule some updates on our device fleet 👍🏻. Our fork has some code to maintain support with an older poppler version which can become a pain when bringing in upstream changes that use newer poppler features.

Pretty cool that it's in production already!
And i guess that explains not taking chances on interface.
I made a backport commit here attah#11 when the required version increased.

Also we have found this Orientation option has no effect on the printed result. However it is mentioned in this document, alas maybe it is a dead setting though like you say?

That's the same standard i meant. It is mentioned, but also doesn't really say what it does (though it seems mandated for compliance). Could be that you need to set the feed orientation too.

With some more thought, since the backside transformations are defined in feed and cross-feed directions, but refer directly to duplex/tumble which is defined in long and short sides... then i don't see any room for non-portrait orientations actually working. I probably should ask the PWG folks.

[jameshalsall]

It is not just --tumble that you are after? (Or missed accounting for pwg-raster-document-sheet-back?)

I haven't had any success with this, or --back-xform: the printer returns a 1041 (document-access-error) in response when trying to spool (Print-Job).

I had assumed that --tumble and --back-xform were only relevant when printing in duplex. We are printing single-sided but the reverse side is pre-printed in bulk in advance to save on print times, but this may be why the printer is unable to process the job because we are using duplex options and not printing in duplex.

[attah]

I had assumed that --tumble and --back-xform were only relevant when printing in duplex.

Correct. I wasn't considering bulk manual duplex.
But then you should be able to manually turn the stack whichever way helps?
(I assume it is at least moved manually, but maybe not)

Anyway, i asked the PWG folks what this is supposed to work like. No answer yet.

[attah]

I heard back. :)
Orientation is only ever so slightly useful. It is basically just a hint to printers, should they want to rotate the output.
I.e. if it is outputting Landscape, and i send a Portrait version of something that originally came in as Landscape, it can undo that "the right way".
I don't see the benefit, especially if it ends up second-guessing my desired rotation in a mixed-orientation document.

Apparently the design requirement of no printer-side transforms needed does not apply here.

Anyway - does that sound like what you wanted to do?
Or now that i know i don't particularly want this, i can at least consider adding something that might otherwise have conflicted.
What is it that you want that the human loading the media couldn't readily achieve?

[jameshalsall]

Orientation is only ever so slightly useful. It is basically just a hint to printers, should they want to rotate the output.

good to know 👍🏻

I think upon further inspection with our operations team this "flip" doesn't actually need to happen, and we can adjust how print media is loaded like you alluded to earlier 👍🏻 thanks