All,
I would also like to discuss the "insert-sheets" attribute. In working on implementing this attribute it has become clear to me that it doesn't interact well with "imposition-template" and is something that could be implemented on the Client side using "overrides" and "force-front-side", much like "cover-front" and "cover-back". So I would also like to DEPRECATE "insert-sheets".
We'll be discussing my PPX prototyping this afternoon during the IPP WG concall...
> On Jun 28, 2022, at 2:27 PM, Michael Sweet <msweet at msweet.org> wrote:
>> All,
>> I have been working on my prototyping of the current PPX draft in the ippsample project (almost done) and wanted to share some initial results:
>> - "imposition-template" is largely a replacement for/superset of "number-up". The current ipptransform code only supports one at a time, with precedence given to "imposition-template".
>> - "imposition-template" (for 'booklet') and "page-ranges" do not interact well, mainly because "page-ranges" applies to input pages and booklet printing rearranged the order and location of the input pages to produce a booklet that can be folded and stapled along the middle of the stack of media sheets.
>> - "cover-back" and "cover-front" are essentially composite attributes for "overrides (1setOf collection)" (PWG 5100.6) and "force-front-side (1setOf integer(1:MAX))" (PPX).
>> Based on these results:
>> - Do we need a way to select output pages (media sheets) as opposed to input pages as supported by STD92's "page-ranges" Job Template attribute? I am not convinced that we *do* need it since the Client can easily prepare document data that doesn't need imposition, but if we do need it we could add a "media-sheet-ranges (1setOf rangeOfInteger(1:MAX))" Job Template attribute...
>> - I would like to DEPRECATE "cover-back" and "cover-front" since they duplicate functionality supported by "overrides" and "force-front-side". I am not aware of any implementations of the cover attributes while "overrides' (at least) is widely supported by PDF printers...
>> Thoughts?
>> ________________________
> Michael Sweet
>
________________________
Michael Sweet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20220707/afb4b4dc/attachment.sig>