Re: Exploring a universal production printing architecture

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 =
workflow.
>=20
> 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.
>=20
> 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