Re: Exploring a universal production printing architecture

Solomon and Michael,

Thank you both. Your responses helped me see that I described this as
a new printing architecture when much of the underlying model may
already exist in IPP.

I also used =E2=80=9Cvirtual driver=E2=80=9D too loosely. I am not proposin=
g a new
printer-specific rendering stack, nor am I suggesting that an
application can postpone decisions affecting its composition or
pagination. If Word must paginate for Letter versus A4, that
document-canvas decision necessarily belongs in the application. My
production-print use case begins after the application has composed
the document. For example, an InDesign document might deliberately
produce a 12.5 =C3=97 19.5-inch page containing the selected bleed, crop
marks, registration marks, and other content. I want the application=E2=80=
=99s
normal Print command to submit that composed output into a persistent
held workflow without requiring the user to select a particular press,
tray, stock, or finisher first. This is not necessarily equivalent to
asking the user to export a PDF. In applications such as InDesign,
printing and exporting can follow different settings and rendering
paths, even when they begin with the same source document. The
resulting page geometry, marks, separations, color handling,
transparency treatment, scaling, and other output characteristics may
differ.

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.

What I am describing therefore creates a persistent production transaction:

Application Print command
-> platform-appropriate logical production destination
-> original submitted print representation is retained
-> held job preserving the composed page geometry
-> operator or automation applies the production ticket
-> final output device and output path are selected
-> IPP, Printer Application, vendor DFE, native driver, shared queue,
or another adapter

EFI Command WorkStation is a familiar proprietary example of the
operator experience I mean. Once a job is held, the operator can still
control media, scaling, duplex, imposition, color processing, image
shifts, finishing, VDP behavior, scheduling, notes, and accounting
before releasing it. I am not proposing that OpenPrinting reproduce
Command WorkStation or Fiery=E2=80=99s RIP functions. The operational gap i=
s
that this workflow is normally attached to a specific vendor DFE and
its connected press. There is also a compatibility and lifecycle
aspect that I did not explain in my first message. I envision the
client-facing submission destination, the workflow appliance, and the
device-specific output paths as separate layers with independent
lifecycles. The client-facing destination would remain available
across current versions of Windows, macOS, Linux, and other platforms.
Its implementation might differ by platform or generation, but each
implementation would submit through the same stable, vendor-neutral
contract. The central workflow could be a comparatively stable,
long-lived appliance or service running on Linux, Windows, or macOS,
with a local, desktop, or web-based operator interface.
Device-specific compatibility would be handled behind the workflow
through whatever output path is appropriate: direct IPP, a Printer
Application, a vendor DFE, a locally installed native driver, an
existing shared queue, or a remote output agent running an operating
system that still supports a legacy driver.

A concrete example from our shop is an HP DesignJet Z5200ps. Its
genuine HP driver and our preferred color workflow remain usable on
certain Intel Macs and older Windows systems, but not on our current
Apple-silicon design workstations. Today, producing the desired output
can require us to create the job in current InDesign on an
Apple-silicon Mac, package or save it for an older InDesign release,
move it to an older Intel iMac, open it there, and finally print
through the genuine HP driver. That makes an obsolete design
workstation part of the production workflow merely because it can
still run the correct printer driver.

In the model I am describing, the modern design workstation would
print application-composed, device-independent content to the logical
production destination. The operator would then select the DesignJet
in the workflow console and apply its production settings. If the
console runs on a Windows machine that supports the genuine HP driver,
the locally installed DesignJet would simply appear as an available
output destination. No additional translation machine would be
necessary. The console could also submit to an existing shared printer
or RIP queue. Our Lanier/Ricoh LW310 wide-format system, for example,
uses a Windows XP-based RIP. That printer can still be shared to
Windows 7 or Windows 10 systems. A workflow console running on one of
those compatible systems could submit directly to the shared RIP
queue.

A separate output bridge would be needed only when the console=E2=80=99s ow=
n
operating system cannot support or reach the required output path. In
that case, an isolated Intel Mac, Windows VM, or physical Windows
system containing the supported native driver could act as a remote
output agent.

The workflow could therefore use:
- a native driver installed on the console host;
- an existing Windows, CUPS, or IPP shared queue;
- direct PDF, PostScript, PCL, or another supported language;
- a vendor DFE such as Fiery; or
- a remote output agent running the operating system required by a
legacy driver.

The output bridge is a compatibility option, not a mandatory part of
every job. The workflow uses the shortest dependable path available
for each device. The important separation remains the same: the design
workstation submits to one durable production destination, while the
workflow console maintains and selects among changing device-specific
output paths. The workflow would always retain the submitted geometry.
If the operator maps a 12.5 =C3=97 19.5-inch document onto another output
size, the resulting crop, fit, or scaling would be explicit rather
than silently conflating document size with loaded media size.

There is a corresponding benefit at the other end of the lifecycle.
The same logical production destination should be reachable from new
categories of client devices without requiring those devices to
understand the eventual production equipment. For example, the
workflow could advertise an AirPrint-compatible logical Printer. A
user designing a document on an iPad Pro could use the application=E2=80=99=
s
normal Print command to submit it to the held workflow. The iPad would
not need an HP DesignJet driver, a Fiery driver, or any knowledge of
the final media, tray, or finishing configuration. The operator could
then inspect the submitted geometry, select the intended output
device, and apply the production settings:

iPad design application
-> AirPrint-compatible logical production destination
-> held job in the workflow
-> operator selects a device and production settings
-> appropriate local driver, shared queue, DFE, or output agent
-> selected production device

An emerging client platform could therefore submit to an older
production device even though no direct driver relationship exists
between them.

I do not expect one literal driver binary to run on every operating
system. I envision a family of platform-appropriate submission
interfaces=E2=80=94IPP/AirPrint, Android or ChromeOS printing, traditional
desktop queues, and possibly a share action or web interface=E2=80=94all
creating the same vendor-neutral Job object through a stable contract.
The client-facing implementations could evolve as operating systems
and processor architectures change, while the central workflow remains
a comparatively stable long-term service and legacy output paths
remain isolated behind it. Where a mobile print dialog cannot express
the intended custom geometry, a share extension or direct workflow
submission interface could provide an alternate path while still
creating the same held job. This is why I see the logical production
destination as something different from installing every physical
printer on every client. The client needs one durable route into the
production system. The production system owns the changing
relationships among modern clients, current devices, vendor DFEs, and
legacy native drivers.

Having begun reading the material you referenced, I see that IPP
already provides much of the vocabulary I was reaching for: Printer,
Job, and Document objects; held jobs; job tickets; settable job
attributes; production-printing attributes; and
shared-infrastructure/proxy concepts.

My corrected questions are:

- 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?
- 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?
- Could locally installed printers, shared queues, and remote systems
running supported native drivers all be represented as output
destinations behind that workflow?
- 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?
- If the standards already express nearly all of this, is the missing
piece primarily a reference workflow implementation and
production-oriented operator interface?

I may not be identifying a standards gap. I may be identifying an
implementation and operator-workflow gap between what IPP can
represent and what production operators can currently use across
mixed-vendor and mixed-generation devices.

Thank you again for correcting my framing. I would appreciate any
pointers toward existing implementations or the most relevant parts of
the Infrastructure Printer/Proxy model.
--
Joshua Braddock
Queen City Print Shop
701.203.2873

Notice: This email, including any attachments, is intended solely for
the use of the designated recipient(s) and may contain confidential or
legally privileged information. If you are not the intended recipient,
you are hereby notified that any review, disclosure, copying,
distribution, or use of this email is strictly prohibited. If you have
received this message in error, please notify the sender immediately
by replying to this email and permanently delete it, along with any
attachments, from your system. Thank you for your cooperation.

On Sat, Jul 18, 2026 at 8:17=E2=80=AFAM Michael Sweet <[email protected]> w=
rote:
>
> Joshua,
>
> I'll preface my feedback with "what Solomon said" since it covers all of =
the important stuff.  My own specific responses are below...
>
>
> > On Jul 18, 2026, at 4:25=E2=80=AFAM, Joshua Braddock - Queen City Print=
 Shop <[email protected]> wrote:
> > ...
> > The core idea is to separate document generation from production workfl=
ow.
> >
> > Today, applications generally render directly to a printer driver,
> > where media selection, finishing, device capabilities, and
> > vendor-specific options are all intertwined.
>
> Actually, that was the 90's.  CUPS started out in 1998 as a PostScript + =
PDF-first solution that isolated applications from generating printer-speci=
fic features/code, and that from an earlier (1994) PostScript implementatio=
n on top of the old System V printing system.  Over the years we have been =
able to get the industry to (more or less) standardize on using IPP and hig=
her-level file formats - the main holdouts are label, receipt, and large-fo=
rmat roll printers, although there has been some adoption in specific marke=
ts.
>
> Some of the resistance to change comes from vendors providing tightly int=
egrated solutions (point-of-sale, shipping, photo, and high-end RIPs) where=
 there is little demand for a more generic, cross platform/vendor solution.=
  Try to convince EPSON that they should put AirPrint in their 24+" roll pr=
inters and they just claim that nobody will print photos from their phone, =
ignoring that the same protocol is used for desktop printing because that w=
ould cut into the business of RIP vendors that help get their products sold=
.
>
> So what we've been doing for the last 16 years is evangelizing standards =
and pragmatically developing and supporting IPP "Printer Applications" for =
those printers that cannot (or will not) support a common standard.  This i=
sn't perfect but it at least makes it possible to create a common workflow =
application based on IPP.
>
> > ...
> > My question isn't whether this should replace CUPS or existing printer
> > drivers. Rather, I'm curious whether OpenPrinting has already explored
> > an architectural separation like this, or whether this is an area
> > where discussion would be appropriate.
> >
> > I'd appreciate any pointers to prior work, existing standards, or
> > reasons this approach has already been considered.
>
> Standards can be found here: https://www.pwg.org/ipp/
>
> The migration of CUPS away from drivers is discussed here: https://openpr=
inting.github.io/cups/drivers.html
>
> ________________________
> Michael Sweet
>