Exploring a universal production printing architecture

Exploring a universal production printing architecture

[Joshua Braddock - Queen City Print Shop]

Hello everyone,

I've spent many years working in commercial production printing with
mixed-vendor environments (Xerox Fiery, HP DesignJet, office printers,
legacy Windows print servers, etc.), and I've been thinking about
whether there is room for a higher-level printing architecture that
complements CUPS rather than replacing it.

The core idea is to separate document generation from production workflow.

Today, applications generally render directly to a printer driver,
where media selection, finishing, device capabilities, and
vendor-specific options are all intertwined.

I'm wondering whether there is interest in an architecture where a
universal virtual printer exists on any supported operating system.
Rather than targeting a physical device, applications would simply
"print" to this virtual destination. The resulting job would then
enter a vendor-neutral workflow system (headless or GUI-based)
responsible for production decisions such as:

- device selection
- media selection
- imposition
- finishing
- routing
- job scheduling
- recovery after interruptions
- accounting and auditing
- communication with vendor-specific drivers, RIPs, or printer applications

The workflow engine could operate as a local application, centralized
server, or completely headless service with a web interface. The
virtual printer would provide a consistent interface to applications,
while the workflow layer would determine how and where jobs are
ultimately produced.

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.

Thank you,
--
Joshua Braddock
Queen City Print Shop (qcprints.net)
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.

Re: Exploring a universal production printing architecture

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 2940 bytes --]

On Sat, Jul 18, 2026 at 02:25:44AM -0600, Joshua Braddock - Queen City Print Shop wrote:
> I'm wondering whether there is interest in an architecture where a
> universal virtual printer exists on any supported operating system.

Isn't this effectively the "print to PDF" option already typically 
present today?  (And I might add, this provides the basis for IPP)

> Rather than targeting a physical device, applications would simply
> "print" to this virtual destination. The resulting job would then
> enter a vendor-neutral workflow system (headless or GUI-based)
> responsible for production decisions such as:

> - device selection
> - media selection
> - imposition
> - finishing
> - routing
> - job scheduling
> - recovery after interruptions
> - accounting and auditing
> - communication with vendor-specific drivers, RIPs, or printer applications

Other than the first two, isn't this already what we have today with 
CUPS *and* IPP?

Keep in mind that the first two have drastic effects on what the 
application needs to produce (ie physical size of pages).  Even in 
"standard office document" territory you have A4 vs Letter output, which 
drastically (and continually) affects the pagination, so you need your 
application to be aware of the constraints that directly flow from the 
output devices's (and selected media)' physical properties.

Or when printing photos (or any single page thing that not an office 
document), different models often/usually have slightly different native 
dimensions/margins/aspect ratios for a given nominal print size, and if 
the application isn't aware of this your "workflow" will produce a white 
margin on one or more sides or crop (perhaps something important) off of 
the others.

> The core idea is to separate document generation from production workflow.

I belive this is the fundemental basis of modern IPP, but...

> I've spent many years working in commercial production printing with
> mixed-vendor environments (Xerox Fiery, HP DesignJet, office printers,
> legacy Windows print servers, etc.), and I've been thinking about
> whether there is room for a higher-level printing architecture that
> complements CUPS rather than replacing it.

...the problem you are having is "proprietary vendors and their 
proprietary solutions suck" -- usually by design.  Once you step beyond 
those constraints, what you appear to be clamoring for already exists.  
(Indeed, there numerous proprietary printing stacks are implemented on 
top of IPP)

(Modern) IPP revolves around applications supplying a PDF and 
specifiying the output "intent" and letting the rest of the system work 
out how best to achieve that.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Exploring a universal production printing architecture

[Michael Sweet]

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 AM, Joshua Braddock - Queen City Print Shop <joshua@qcprints.net> wrote:
> ...
> The core idea is to separate document generation from production workflow.
> 
> 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-specific features/code, and that from an earlier (1994) PostScript implementation 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 higher-level file formats - the main holdouts are label, receipt, and large-format roll printers, although there has been some adoption in specific markets.

Some of the resistance to change comes from vendors providing tightly integrated 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 printers and they just claim that nobody will print photos from their phone, ignoring that the same protocol is used for desktop printing because that would 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 isn'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://openprinting.github.io/cups/drivers.html

________________________
Michael Sweet