Print Rendering Pipeline

Overview

The print rendering pipeline is the end-to-end chain of software and firmware components that turns an application's abstract description of a page into physical marks on paper. It spans three broad stages: (1) an application emits a page description through the operating system's graphics or printing API; (2) the OS spools the job and passes it through a chain of drivers or filters that translate it toward a form the target device accepts; and (3) a raster image processor (RIP) converts the page description into a raster bitmap of dots, which the print engine finally lays down as toner or ink.

A defining question at every stage is where rasterization happens. In device-based rendering, the host sends a compact page-description language (PDL) — PostScript, PCL, or PDF — and the printer's onboard RIP does the heavy work. In host-based rendering, the host software rasterizes to a device-ready raster and the printer does little beyond marking. Modern systems increasingly use a third model — driverless printing, where the host sends a standardized document format over the Internet Printing Protocol (IPP) and the device advertises its own capabilities.

Both dominant OS families — Windows and CUPS-based systems — ultimately implement the same conceptual pipeline: application to OS graphics layer to spool format to filter/driver chain to RIP to device raster to marking engine.

History

The pipeline's architecture is inseparable from the invention of the page-description language and the laser printer. Xerox's Palo Alto Research Center (PARC) invented the laser printer and, in the late 1970s, pursued a device-independent imaging approach so any computer could drive any printer through a common language. John Warnock (hired by Chuck Geschke into PARC's Imaging Science Laboratory in 1978) and Martin Newell built an early procedural graphics language, JaM, which fed into Xerox's Interpress printing language (1979–1981).

Geschke and Warnock left PARC and founded Adobe Systems in December 1982, releasing PostScript in 1984 — a geometric, procedural language that treated text and images uniformly as scalable mathematical descriptions. In the 1990s Warnock championed PDF (Portable Document Format), a self-contained document derivative of the PostScript imaging model, which eventually displaced PostScript as the interchange and, on modern systems, the spool format.

In parallel, HP's PCL (Printer Command Language) provided a lighter-weight PDL widely used in office printers, and Microsoft built its own host-side pipeline around GDI and later XPS. On UNIX, CUPS (Common UNIX Printing System) standardized around IPP and a filter/backend model, was adopted by Apple for macOS, and later shifted its internal workflow from PostScript to PDF as the standard print-job format.

Architecture

Both OS families share a common set of conceptual layers:

• Application / graphics API — where the page is described (drawing calls or a document format).
• Spooler / scheduler — queues jobs, decouples the application from the device, applies job control, and dispatches the conversion chain.
• Conversion chain — driver components (Windows) or filters (CUPS) that translate the spool format toward the device's language.
• RIP — rasterizes the page description into a bitmap; may live on the host or in device firmware.
• Transport / back end — a port monitor or backend that ships bytes over USB or the network.

Windows (per Microsoft Learn) has two primary print paths — the GDI print path and the XPS print path — bridged by two conversion modules: GDI-to-XPS conversion (the Microsoft XPS Document Converter, MXDC) and XPS-to-GDI conversion (XGC). Spool formats are EMF (Enhanced Metafile), a recording of GDI drawing calls, for the GDI path, and the XPS spool file (an OPC/ZIP package of XAML-based fixed-page markup) for the XPS path. A printer driver combines a rendering component and a configuration component: GDI drivers use a printer graphics DLL and a printer interface DLL, while XPSDrv drivers use a filter pipeline and the XPSDrv Render Module. Two driver models exist — the GDI-based v3 model (including the XPSDrv extension) and the v4 model. Microsoft now recommends the IPP inbox class driver plus Print Support Apps (PSA) as the modern platform for Windows 10/11.

CUPS (per OpenPrinting documentation) centers on the scheduler cupsd, described as an HTTP/1.1 and IPP/2.1 server whose helper processes normally run as the non-privileged lp account. Configuration files include cupsd.conf, classes.conf, printers.conf, subscriptions.conf, mime.types, mime.convs, and per-printer PPD (PostScript Printer Description) files in the classic architecture. Jobs are stored in /var/spool/cups as control files (beginning with c) and data files (beginning with d), with logs in /var/log/cups. Filters chain stdin-to-stdout to convert the job toward the device format; port monitors (bcp, tbcp) format channel data; and backends deliver data and enumerate devices over AppSocket (JetDirect), IPP, LPD, and USB, plus DNS-SD and SNMP for discovery. The shared libcups library carries the core HTTP and IPP code. CUPS Raster (application/vnd.cups-raster) is a streamable device-dependent raster whose per-page header combines a PostScript page device dictionary with raster fields such as cupsBitsPerColor, cupsColorSpace, cupsWidth, and cupsHeight.

How it works

1. The application describes a page. It issues drawing calls (Windows GDI; macOS Quartz 2D / Core Graphics) or hands over a document format. Quartz 2D is a resolution- and device-independent engine, and per Apple's Quartz 2D overview its drawing model is based on the PDF specification. 2. The OS captures the description into a spool format. Windows records GDI calls as EMF, or spools an XPS package; CUPS-based applications typically submit PDF or an image/text type. The spooler enqueues the job so the application can return quickly. 3. The job is dispatched through the conversion chain. On Windows the spooler invokes the print processor — the EMF print processor lives in localspl.dll and replays the recorded GDI calls back through GDI and the printer graphics DLL. On CUPS, cupsd consults mime.convs and the PPD to compute the least-cost filter chain from the job's MIME type to the printer's format. 4. Rasterization happens where the device requires it. If the device understands a PDL, the host emits that PDL and the printer's firmware RIP rasterizes. If the device is host-rendered, a software RIP on the host (for example Ghostscript, or Windows GDI rendering into the printer graphics DLL) produces a device raster; in CUPS a filter such as pdftoraster or gstoraster produces CUPS Raster, then a device filter converts it to the printer's byte stream. 5. Transport. A Windows port monitor and port driver, or a CUPS backend, ships the bytes to the device. 6. Marking. The print engine converts the raster into marks on paper, using halftoning or screening to render continuous tones as dot patterns.

The rendering-locus contrast is explicit in OS documentation: EMF is a closed format that represents application output as a series of GDI calls that then require calls into GDI for rendering services, whereas the XPS spool format represents the actual visual output without requiring further interpretation when targeting an XPSDrv driver, allowing that driver to operate directly on the spool data.

Data flow

Windows — GDI print path: Win32/GDI app → GDI (CreateDC → DrvEnableDriver → DrvEnablePDEV) → EMF spool file → spooler → EMF print processor (localspl.dll) replays EMF → GDI plus printer graphics DLL render → device data stream (EngWritePrinter / WritePrinter) → port monitor and port driver → device.

Windows — XPS print path: WPF app or the XPS Print API → XPS spool file (OPC/ZIP plus XAML) → spooler → XPSDrv filter pipeline (XPSDrv Render Module, v4 render, or a Print Class Driver) → device PDL or raster → port → device. MXDC converts GDI to XPS for XPS devices; XGC converts XPS to EMF for GDI/v3 devices.

CUPS / macOS / Linux: Application (AppKit → Core Printing → CUPS on macOS, or an lp/lpr/IPP client) → cupsd enqueues the job (control c-file plus data d-file in /var/spool/cups) → filter chain (for PDF: pdftopdf → pdftoraster/gstoraster → CUPS Raster → device raster filter) → optional port monitor → backend (usb, ipp, socket, lpd) → device (firmware RIP if a PDL device).

Driverless (IPP-based): Application → client sends a standardized format over IPP → the printer's own processor renders → engine.

Operating system integration

On Windows, the pipeline is a first-class OS subsystem: the print spooler service, the kernel-mode graphics engine (GRE), the print processor, and a driver store spanning the v3 (GDI/XPSDrv) and v4 models. Applications reach it through GDI, the XPS Print API, or WPF. The modern print platform for Windows 10/11 centers on the IPP inbox class driver and Print Support Apps rather than vendor kernel or user drivers.

On macOS, printing is layered as AppKit (NSView/NSDocument printing) → Core Printing (a C API) → CUPS. Application developers normally interact only with AppKit, while CUPS provides queue management and device communication underneath. The system's drawing foundation, Quartz 2D (Core Graphics), uses a PDF-based imaging model.

On Linux and other UNIX-like systems, CUPS is the standard printing system, with cups-filters from OpenPrinting supplying filters and backends, and Ghostscript, Poppler, or MuPDF as PDF/PostScript renderers. CUPS also exposes the legacy System V (lp, lpadmin, lpstat, cancel) and Berkeley (lpr, lpq, lprm, lpc) command sets, and accepts inbound LPD jobs via cups-lpd. The CUPS 3.x "New Architecture" is all-IPP and driverless-only, dropping PPD files and classic drivers and moving device-specific logic into self-contained Printer Applications; cups-filters 2.x retrofits filter functionality for CUPS 2.x.

Relationship to standards

• IPP (Internet Printing Protocol): the transport and semantics backbone of CUPS and driverless printing, maintained by the PWG. Core specifications are RFC 8011 (IPP/1.1: Model and Semantics, January 2017, obsoleting RFC 2911) and RFC 8010 (IPP/1.1: Encoding and Transport, January 2017, obsoleting RFC 2910). cupsd speaks IPP/2.1 over HTTP.
• PWG standards: IPP Everywhere, which lets computers and mobile devices find and print to networked and USB printers without vendor-specific software, and PWG Raster as a standardized raster document format.
• PDF: the imaging model behind macOS/Quartz and the standard CUPS print-job format. PDF was standardized as ISO 32000-1:2008 (derived from PDF 1.7) and ISO 32000-2 (PDF 2.0, first published 2017 and revised 2020).
• PostScript: Adobe's PDL and imaging model, also the basis of the PPD file format and the page device dictionary embedded in CUPS Raster headers.
• RFC 1179 (LPD/LPR): the legacy line-printer protocol, supported by CUPS via cups-lpd.
• XPS / OpenXPS: Microsoft's XML fixed-document and spool format using OPC/ZIP packaging and XAML markup, the native format of the Windows XPS print path.
• Driverless ecosystems such as AirPrint and Mopria ride on IPP and PWG or vendor raster formats.

Relationship to technologies

• Page-description languages (PDLs): PostScript, PCL / PCL XL, and PDF — the descriptions the host may send when the device has its own RIP.
• Raster image processor (RIP): the rasterization engine, on host or device. Ghostscript is the dominant open-source host RIP; the cups-filters/Ghostscript stack uses output devices such as cups (CUPS Raster), pwgraster, appleraster, pclm, and pdfwrite. Poppler and MuPDF are alternative PDF renderers.
• Spool and intermediate formats: EMF and XPS on Windows; PDF, CUPS Raster, PWG Raster, Apple Raster, and PCLm on CUPS and driverless systems.
• Graphics engines: Windows GDI/GDI+ and the XPS/WPF stack; macOS Quartz 2D / Core Graphics with its PDF imaging model. These define the drawing primitives — paths, glyphs, images, gradients, transparency — that must survive translation to the device.
• Fonts: outline fonts (Type 1, TrueType, OpenType) and font subsetting, an explicit optimization in the XPS spool path and in PDF-based workflows.

The RIP is the component that consumes a PDL, PDF, or raster and produces device pixels; the choice of PDL determines whether that RIP runs in the printer or on the host.

Relationship to manufacturers

• Adobe created PostScript and PDF — the imaging models underlying much of the pipeline — and licensed PostScript broadly to computer and printer makers.
• Xerox / PARC invented the laser printer and the precursor languages (JaM, Interpress) that shaped device-independent page description.
• Apple shipped an early PostScript laser printer (the LaserWriter, 1985) that helped catalyze desktop publishing, later built macOS printing on CUPS and Quartz, and defined AirPrint.
• HP created PCL and, with the LaserJet line, drove its ubiquity; PCL and PCLm remain common device languages.
• Microsoft defined the Windows GDI/EMF and XPS print paths, the v3 and v4 driver models, and the modern IPP-class-driver plus PSA platform.
• The PWG and OpenPrinting are vendor-neutral bodies: the PWG standardizes IPP and PWG Raster, while OpenPrinting maintains CUPS, cups-filters, and the driverless / Printer-Application direction.

Printer vendors historically supplied PPDs for PostScript/CUPS and v3/v4 drivers or XPSDrv filters for Windows; driverless standards are steadily reducing the need for vendor-specific drivers.

Modern relevance

The pipeline is shifting decisively toward driverless, PDF- and raster-standard, IPP-based printing. OpenPrinting replaced PostScript with PDF as the standard CUPS print-job format; CUPS 3.x removes PPDs and classic drivers, pushing device logic into Printer Applications; and Microsoft steers Windows 10/11 toward the IPP inbox class driver plus Print Support Apps.

Driverless ecosystems such as AirPrint, Mopria, and IPP Everywhere mean most current printers advertise their capabilities and accept a standardized format directly, collapsing much of the historical host-side driver chain. At the same time, Ghostscript and the CUPS Raster path remain essential for the large installed base of non-IPP and host-rendered printers.

Common misconceptions

• "EMF or the XPS spool file is what the printer prints." No. EMF is a recording of GDI calls that must be replayed and rendered; only the XPS path can, for an XPSDrv device, hand the spool data to the driver without further interpretation.
• "Rendering always happens in the printer." False. Rasterization can occur on the host (host-based printers, or software RIPs like Ghostscript) or in the device; the location depends on the device's capabilities.
• "PDF and PostScript are the same thing." They share an imaging model and lineage, but PDF is a self-contained document format standardized as ISO 32000, while PostScript is Adobe's programming-language PDL.
• "CUPS is a Linux-only technology." CUPS is the printing system on macOS as well and is used across UNIX-like operating systems.
• "A PPD is a driver." A PPD describes a PostScript printer's capabilities and options; the actual conversion is done by filters and RIPs. CUPS 3.x removes PPDs altogether.
• "The spooler renders the page." The spooler or scheduler queues and dispatches; rendering is done by the RIP, driver, or filter components it invokes.
• "XPS fully replaced GDI." The GDI path remains for Win32 applications and GDI devices, with MXDC and XGC bridging the two paths.

Timeline

1. Late 1970s

   Xerox PARC invents the laser printer and pursues device-independent page description.

2. 1978

   Chuck Geschke hires John Warnock into PARC's Imaging Science Laboratory; work on the JaM language begins.

3. 1979–1981

   JaM feeds into Xerox's Interpress printing language.

4. December 1982

   Adobe Systems is founded by Geschke and Warnock.

5. 1984

   PostScript is released by Adobe.

6. 1985

   Apple's LaserWriter, an early PostScript laser printer, helps launch desktop publishing.

7. 1990s

   Warnock champions PDF, derived from the PostScript imaging model.

8. 2008

   PDF is standardized as ISO 32000-1:2008 (from PDF 1.7).

9. January 2017

   RFC 8010 and RFC 8011 are published, updating IPP/1.1 and obsoleting RFCs 2910 and 2911.

10. 2010s

    OpenPrinting shifts the CUPS workflow to PDF as the standard print-job format and expands cups-filters.

11. 2020s

    The move toward the CUPS "New Architecture" (all-IPP, driverless, Printer Applications) and Windows' IPP class driver plus PSA as the recommended platform.