Re: Exploring a universal production printing architecture

Joshua,

> On Jul 18, 2026, at 11:34=E2=80=AFAM, Joshua Braddock - Queen City =
Print Shop <[email protected]> wrote:
> ...
> What I want to preserve is the output composed by the application
> through its normal Print path. The logical production destination
> would capture that submitted print content and create a persistent
> held job from it. The underlying transport representation might be
> PDF, PostScript, XPS, PWG Raster, or another standard format,
> depending on the application and operating-system print path. The
> important point is that the workflow receives what the application
> submitted for printing rather than requiring the user to perform a
> separate PDF export. The workflow could retain that original submitted
> representation and, when necessary, create a normalized production
> document for previewing, transformation, routing, or output. Any
> normalization would be recorded as a derivative rather than silently
> replacing the submitted source.

For macOS or Linux, the standard output from an application is almost =
always PDF.  The few that don't are specialized applications (shipping =
and other label stuff, point of sale, etc.) or (if you are using a =
PostScript printer with an Adobe application) PostScript.

For Windows everything ends up as XPS or (in the case of PostScript =
printers and Adobe applications) PostScript.

> ...
> My corrected questions are:
>=20
> - Is an IPP Infrastructure Printer, Printer Application, or another
> existing IPP model the appropriate basis for a logical production
> destination that is not initially bound to one output device?

Yes.

> - Can an operator-facing application hold a submitted job, modify its
> production attributes, and then route or reproduce it against a
> selected Printer while remaining within existing IPP semantics?

IPP allows for this, and operator overrides get reflected in the =
"xxx-actual" attributes.

> - Could locally installed printers, shared queues, and remote systems
> running supported native drivers all be represented as output
> destinations behind that workflow?

Yes.

> - Is there an existing open-source implementation that combines these
> concepts into a mixed-vendor production console rather than presenting
> them as unrelated individual device queues?

I am not aware of one.

> - If the standards already express nearly all of this, is the missing
> piece primarily a reference workflow implementation and
> production-oriented operator interface?

Yes.

________________________
Michael Sweet