Re: Exploring a universal production printing architecture

[Solomon Peachy <pizza@shaftnet.org>]

[-- 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 --]