Re: Exploring a universal production printing architecture

--WRbEwD6+uXmiaJL8
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 18, 2026 at 02:25:44AM -0600, Joshua Braddock - Queen City Prin=
t 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=20
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 applicatio=
ns

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

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

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

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

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

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

--WRbEwD6+uXmiaJL8
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE3H5Sx9DyiyB5hnENrGLLO/XVulEFAmpbbGMACgkQrGLLO/XV
ulH8VA//YouyIeXWZzIPOfUdsQxjtrSEe7SBf8SERYBE4u0BWRBiJZOgOwIMCFsq
GInr81JbeijP5o8ZO/YbSeV4h52asryTRTqhFY2A83dLKAHHdSCKovI5a8KVE2T7
DC9hWomiGsAXt/dGzPTGzKEU7SLBLSITOXF2JFCf8/iJZRVUqDlHrVoA41Rt0Taa
eqIhq8E6952Y28icWVhA53MoZBAWvbwV41xVnn7SD2nFOwr6Q7MAWXM7XSfW8o9s
a85uy2+Yf8zHEd6dHcPgXKpDyAcTaeQO5zr/s1cm0UB6Zh2V2YRmkWH8m7Auu7sf
xoQNUPfE/BCrpdi7izu+GPSnoW5S1NlQJgRnIoyTGOsW9/A87BginjGw46XjQwzm
iMlXPP1NNIEvjGHJZSVK44fvWrSYIouycLoLh5pX0gYIsyiiEbp8kqk3qcOOJc0t
MATq//wdXxGE71M1NfEd125tdO870TB6ez3t/pNEu8TJNO/FURLNnEY1y1UmDT5y
QcCz5BKo5qRnVto9BmjuEqVBAyr9v0kX0wHZQsDcLukudYRglZUOOgnAYGUpLbr8
QWAjBOskRUfmXNWa+EjlNPfTeuId/JdRAaeoq5ZBZGqX8S0OqMIgfda6hMvhvx5V
wya1PA3w7RWPSLcEJ0MbqQj7qfcr/eOG5SquQYqYtPsUqa9zwLc=
=O6aE
-----END PGP SIGNATURE-----

--WRbEwD6+uXmiaJL8--