support for IPP page/sheet overrides in LLCP printing esp. tray selection and dynamic duplex

Idea Place
1

I suggest to implement the following feature:

Please consider support for IPP page/sheet overrides in LLCP printing, especially for tray selection and dynamic duplex handling.

With the upcoming direct IPP support for LLCP, the next important step would be to expose those IPP capabilities that are needed for real-world production printing scenarios. A typical use case is already well known from classic List & Label on Windows: different layout regions can use different printer settings, including paper bin/tray and duplex settings. This enables scenarios such as:

  • first page from letterhead tray, following pages from plain paper tray

  • last page from a dedicated payment form tray

  • different copies or layout regions using different paper sources

  • first page simplex, following pages duplex

  • mixing simplex and duplex sections within one logical print job

For PDF output, page orientation can usually be handled by the generated PDF itself. However, paper source selection and dynamic duplex are not really PDF content features. They belong to the print job ticket. In IPP this is already standardized.

Relevant PWG specifications:

  • PWG 5100.6 – IPP: Override Attributes for Documents and Pages
    Defines the overrides Job Template attribute, allowing selected pages/documents to use different Job Template attributes than the job as a whole.

  • PWG 5100.7 – IPP Job Extensions v2.1
    Defines and extends media-col, including media-related job attributes.

  • PWG Media Standardized Names
    Defines standardized media source names such as tray-1, tray-2, by-pass-tray, manual, etc.

A possible IPP mapping would be:

  • default job settings: sides, media, media-col

  • page/sheet specific overrides: overrides

  • tray selection: media-col with media-source

  • dynamic duplex: sides inside overrides

  • capability checks: overrides-supported, media-col-supported, media-source-supported, sides-supported, media-col-ready, media-col-database

Conceptually, LLCP could expose this as a cross-platform abstraction similar to:

var options = new PrintJobOptions
{
    PaperSize = "A4",
    Duplex = DuplexMode.LongEdge,

    PageOverrides =
    {
        new PrintPageOverride(1, 1)
        {
            MediaSource = "tray-1",
            Duplex = DuplexMode.None
        },
        new PrintPageOverride(2, int.MaxValue)
        {
            MediaSource = "tray-2",
            Duplex = DuplexMode.LongEdge
        }
    }
};

This would not necessarily require LLCP to implement printer discovery. The user could still pass the IPP endpoint directly, as planned for the new direct IPP backend. The feature request is specifically about exposing IPP job ticket capabilities that are already standardized and that map well to existing List & Label concepts.

From a List & Label perspective, this would be especially valuable because it would preserve an important classic Windows printing feature in LLCP/headless/server scenarios: layout-region-dependent printer behavior.

The current LLCP PDF printing API already covers job-level options such as paper size, copies and duplex. What is currently missing is a way to express page- or sheet-level overrides. Without this, complex production printing scenarios require workarounds such as splitting the PDF into several jobs or creating separate printer queues with different defaults. That works in simple cases, but it loses atomicity, complicates error handling and makes job status/diagnostics much harder.

Suggested scope:

  1. Support overrides for IPP printers where overrides-supported advertises the requested attributes.

  2. Support media-col/media-source for tray selection.

  3. Support sides in overrides for dynamic simplex/duplex sections.

  4. Report unsupported combinations clearly instead of silently ignoring them.

  5. Keep orientation primarily PDF-driven; IPP orientation-requested is less important for PDF-based LLCP output.

  6. Provide diagnostics showing which IPP attributes were sent and which capabilities were discovered.

This would make the new direct IPP backend much more useful for real-world business printing, especially for invoices, delivery notes, letterhead printing, payment forms and other document types where paper source and duplex rules are part of the actual business process.