Printer driver
View on Wikipediafrom Wikipedia
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
In computers, a printer driver or a print processor is a piece of software on a computer that converts the data to be printed to a format that a printer can understand. The purpose of printer drivers is to allow applications to do printing without being aware of the technical details of each printer model.
Printer drivers should not be confused with print spoolers, which queue print jobs and send them successively to a printer.
Printer drivers in different operating systems
[edit]Unix and Unix-like
[edit]Unix and other Unix-like systems such as Linux and OS X use CUPS (short for Common Unix Printing System), a modular printing system for Unix-like computer operating systems, which allows a computer to act as a print server. A computer running CUPS is a host that can accept print jobs from client computers, process them, and send them to the appropriate printer. Printer drivers are typically implemented as filters. They are usually named the front end of the printing system, while the printer spoolers constitute the back end.
Backends are also used to determine the available devices. On startup, each backend is asked for a list of devices it supports, and any information that is available.
DOS
[edit]DOS supports predefined character devices PRN:, LPT1:, LPT2: and LPT3: associated with parallel printers supported in the system. Similarly, serial printers can be used with AUX:, COM1:, COM2:, COM3: and COM4:.
Users can use commands like, for example, "COPY file1 LPT1:" to print the content of a file to a printer. The contents is transferred to the printer without any interpretation. Therefore, this method of printing is either for files already stored in the corresponding printer's language or for generic text files without more than simple line-oriented formatting.
DOS also provides a dynamically loadable print spooler named PRINT as well as optional support to support screen captures also in graphics mode through GRAPHICS. If the optional character device driver PRINTER.SYS is loaded, DOS provides its code page switching support also for the associated printers—different types of dot matrix and ink jet printers are supported by default.
Beyond this, there are no system-wide printer-specific drivers for use at application level under MS-DOS/PC DOS. Under DR-DOS, however, the SCRIPT command can be loaded to run in the background in order to intercept and convert printer output from applications into PostScript to support PS-capable printers also by applications not supporting them directly.
In order to support more complex printing for different models of printers, each application (e.g. a word processor) may be shipped with its own printer drivers, which were essentially descriptions of printer escape sequences. Printers, too, have been supplied with drivers for the most popular applications. In addition, it's possible for applications to include tools for editing printer description, in case there was no ready driver. In the days when DOS was widely used, many printers had emulation modes for Epson FX-80[1] and IBM Proprinter commands. Many more recent laser printers also have emulation modes for HP PCL (HP LaserJet) or PostScript printers which will work in DOS. It appears that these are also compatible with Windows 3.x.[2]
Windows
[edit]On Microsoft Windows systems, printer drivers make use of GDI (Unidrv or PScript-based) or XPS (XPSDrv). Programs then use the same standard APIs to draw text and pictures both on screen and on paper. Printers which use GDI natively are commonly referred to as Winprinters and are considered incompatible with other operating systems, although there is software (such as PrintFil) which will make these printers work in a DOS prompt within Windows.
Win32 APIs also allow applications to send data directly to the spooler, bypassing the printer driver; however, few applications actually use this option.
The printer driver is usually located on the C:\Windows\System32\DriverStore\FileRepository folder on a Windows machine.
Amiga
[edit]The original AmigaOS up to 1.3 supported printers through a standard series of drivers stored at the required path "DEVS:Printers". All printer drivers were stored in that directory, and covered the standard printers in 1985-1989 circa, included Epson FX standard driver, Xerox 4020, HP, etcetera.
Any Amiga printer driver had to communicate though the standard Amiga printer.device (the default standard hardware device of Amiga dealing with printers), and the standard parallel.device (which controlled parallel port) and the driver would then control the printer on its own.
Amiga printer drivers were an innovation for their time. They spared users from individually configuring each of their applications. They had the ability to print up to 4096 colors.
Through the use of the Printer Preferences program printers could be connected to the serial port as well.
Amiga also had support for a virtual device "PRT:" to refer to printer.device so, for example the command "COPY file TO PRT:" caused the file to be printed directly bypassing parallel.device and the default printer driver. Amiga used ANSI escape codes, not the special ones defined by the various printer manufacturers. This way every application on the Amiga could use the same standard set of control sequences and wouldn't need to know which printer is actually connected. The printer driver then translated these standard sequences into the special sequences a certain printer understands.
Amiga internal function "PWrite" of printer.device writes 'length' bytes directly to the printer. This function is generally called on by printer drivers to send their buffer(s) to the printer. Number of buffers are decided by the persons who created the driver. Amiga lacked a standard Printer Spooler.
Since AmigaOS 2.0 a standard printer.device was changed to control various printers at same time. The Printer preferences were divided in three main panels: Prefs:Printer which selects main printer and other basic elements such as "Print Spacing" and "Paper Size". PrinterGFX controlled features like Dithering and Scaling. PrinterPS controlled Postscript Printers. The printer drivers surprisingly remained almost same of Workbench 1.3, with 4096 limits.
This fact led Amiga users to prefer third party Printer Systems with their own drivers, like TurboPrint and PrintStudio, which introduced not only recent drivers, but also featured a functioning Printer Spooler into Amiga, and featured 16 million colors printing. MorphOS uses a special version of TurboPrint to pilot recent printers.
Many Amiga programs like DTP programs as PageStream featured in the past its own printer drivers.
USB printers are automatically recognized by the Poseidon USB Stack. This stack is capable of detecting any USB device by its class, but printers still require a driver to be controlled.
Types of drivers
[edit]In addition to being install-able on a computer, drivers could also be present in the embedded firmware of printers and made available through a networking protocol (e.g. IPP). The embedded firmware of a printer could thus eliminate the need to install any driver on a computer, by accepting print data in a general purpose format (e.g. PDF) via a networking protocol. Despite some efforts to standardize various stages of the printing pipeline, printer interfaces are largely still very proprietary and manufacturer-specific. Hence, nature of functions performed by drivers can vary. Nonetheless, based on the function performed, drivers can be classified as follows.
Device-independent converters
[edit]These drivers can convert print data from one general purpose format (e.g. PDF, DVI etc) to another general purpose format (e.g. PS). Examples include Ghostscript, etc.
Converters to device-specific format
[edit]These drivers convert print data from one format (e.g. PS) to a final device-specific format that the printer hardware can process and create a print. These drivers act as the last stage in delivering a print job to the printer. These drivers are more likely to be embedded in printer firmware.
Examples of manufacturer specific formats include:
- Printer Command Language (PCL) (Hewlett-Packard)
- PostScript (PS) (Adobe)
- Ink Jet Printer Data Stream (Kodak)
- Samsung Printer Language
- Ultra Fast Rendering (Canon)
Packaging formats
[edit]Install-able drivers can be packaged in various formats. PPD is a popular packaging format for drivers that accept Postscript data or PDF data as input. Due to dominance of select operating systems, the operating system–driver interface is more standardized than driver–printer interfaces. Hence there is more standardization in packaging formats of drivers than the actual functions performed by drivers.
- PostScript Printer Description file Usually the operating system needs to know the characteristics of a printer. The PPD files are the normal way to supply this information. They have the advantage of being system independent, and there is a freely available large database of them, Foomatic.
- CUPS filter This format is used by CUPS on Linux systems.
See also
[edit]References
[edit]Printer driver
View on Grokipediafrom Grokipedia
Fundamentals
Definition and Purpose
A printer driver is a software interface that acts as a translator between computer applications and printer hardware, converting abstract print commands from applications, typically spooled by the operating system in formats such as Enhanced Metafile (EMF) or XML Paper Specification (XPS), into low-level, device-specific commands that the printer can execute.[2] The core purpose of a printer driver is to facilitate seamless communication between the operating system's generic printing application programming interfaces (APIs) and a wide variety of printer models, ensuring compatibility across hardware differences while optimizing for features like resolution, color accuracy, and media handling to produce high-quality output.[2] Key components of a printer driver typically encompass a rendering module, often incorporating a raster image processor (RIP) to transform vector graphics, text, and images into printable bitmap formats; font handlers for substituting and rendering typefaces compatible with the printer's built-in capabilities; and error management routines to detect, report, and recover from issues like communication failures or resource constraints during the printing process.[3][5][6][7]Role in the Printing Pipeline
The printing pipeline encompasses several sequential stages that transform digital content from applications into physical output on a printer. These stages typically include spooling, where print jobs are queued and temporarily stored to manage multiple requests efficiently; rendering, involving the conversion of job data into a printer-compatible format; and transmission, where the processed data is sent to the printer hardware via appropriate ports or networks. This structured flow ensures reliable operation across diverse printing environments, allowing applications to submit jobs without direct hardware interaction.[2][8] Printer drivers play a pivotal role in the rendering stage of this pipeline, acting as the intermediary that receives spool file formats, which may include page description languages (PDLs) such as XPS (in Windows XPSDrv architectures) or PostScript and PDF (in Unix-like systems via CUPS), depending on the operating system and printing architecture. The driver interprets or emulates this input, applying necessary transformations like rasterization for bitmap printers or generating device-specific commands for laser or inkjet models, ultimately producing output data tailored to the printer's capabilities. For instance, in rasterization, the driver converts vector-based descriptions into pixel-level bitmaps, while emulation might translate standard formats into proprietary printer languages to ensure compatibility. This transformative function bridges the gap between high-level application output and low-level hardware instructions, enabling precise reproduction of text, graphics, and images.[2][9] Drivers interact closely with system spoolers to handle job attributes throughout the pipeline, such as specifying paper size, color mode (e.g., grayscale or CMYK), and resolution (e.g., 600 dpi). In systems like CUPS for Unix-like environments, the spooler passes these attributes to the driver during job submission, allowing it to adjust rendering parameters dynamically; similarly, in Windows, the spooler incorporates layout and control directives into the job stream before driver processing. This collaboration optimizes resource use and maintains job integrity from queuing to output.[8][10] In the pipeline, drivers also contribute to error handling by detecting incompatibilities early, such as unsupported fonts that could lead to substitution or garbling, or invalid media types like non-standard paper sizes that might cause jams. Upon identifying these issues during rendering, the driver can alert the spooler to pause the job, notify the user, or fallback to compatible alternatives, thereby preventing failed prints and minimizing waste. This proactive validation ensures the pipeline's robustness, with the driver serving as a key checkpoint before transmission to the hardware.[8][2]History and Evolution
Early Development
In the pre-1980s era, printer drivers for dot-matrix and daisy-wheel printers in mainframe environments were rudimentary, often consisting of basic control sequences integrated directly into the printer's firmware or the host system's operating software to manage simple text output and line feeds.[11] These early implementations, used with impact printers like the Centronics 101 dot-matrix model introduced in 1970, prioritized reliability for high-volume data processing over graphical capabilities, with minimal abstraction between the computer and hardware.[12] Daisy-wheel printers, invented in 1970 by Diablo Data Systems, similarly relied on firmware-embedded codes to rotate and strike character wheels, handling character-based printing without dedicated software drivers in many cases.[13] The 1980s marked significant breakthroughs in printer driver technology, particularly with the introduction of graphical capabilities through page description languages. Apple's LaserWriter, released in March 1985, featured a built-in Adobe PostScript interpreter, enabling high-resolution (300 dpi) vector-based printing that supported complex graphics and fonts directly from the Macintosh system.[14] This driver innovation, paired with software like Aldus PageMaker, revolutionized desktop publishing by allowing WYSIWYG (What You See Is What You Get) workflows, shifting printing from text-only to professional layout design and driving widespread adoption of personal computing for graphic arts.[14] Microsoft's release of Windows 3.0 in 1990 further standardized printer drivers through enhancements to the Graphics Device Interface (GDI), providing a unified API for rendering graphics and text to diverse output devices like inkjet and laser printers.[15] This allowed developers to create more consistent drivers that abstracted device-specific details, supporting features like scalable fonts and improved spooler integration, which became essential for the growing ecosystem of office printers.[16] In parallel, Unix systems contributed foundational abstractions via the Berkeley Software Distribution (BSD). The 4.2BSD line printer spooler, documented in 1983 and refined by 1984, introduced the Line Printer Daemon (LPD) protocol for managing multiple local and remote printers through a centralized configuration file (/etc/printcap), enabling filters to convert input data for device-specific formats.[17] This system laid the groundwork for network printing and device independence in Unix-like environments, supporting raster and laser printers while handling job queuing and administration via commands like lpr and lpc.[17] Early development also grappled with the diversity of proprietary printer languages, necessitating drivers capable of translating host commands into vendor-specific codes. Epson's ESC/P (Epson Standard Code for Printers), introduced in 1980 with the MX-80 dot-matrix printer, provided a command set for controlling text, graphics, and paper handling, becoming a de facto standard for impact printers.[18] Similarly, Hewlett-Packard's Printer Command Language (PCL), debuted in 1984 with the HP ThinkJet inkjet and LaserJet models, offered scalable commands for text and simple graphics at 150-300 dpi, addressing compatibility challenges across emerging non-impact printers.[19] These languages required drivers to embed escape sequences, ensuring reliable output amid varying hardware protocols.[19][18]Modern Advancements
In the 2000s, printer drivers began evolving toward universality to simplify deployment across diverse hardware. Adobe's Universal PostScript Windows Driver, introduced for Windows 2000 and subsequent versions, enabled printing to any PostScript Level 2 or 3 compatible printer without model-specific installations, leveraging a single driver package for broad compatibility.[20] Similarly, Microsoft's XPSDrv, launched with Windows Vista in 2007, served as an enhanced GDI-based printer driver model that supported XML Paper Specification (XPS) output, allowing device-independent rendering and reducing the need for proprietary drivers by standardizing print job processing.[21] Advancements in cloud and network printing during the 2010s integrated drivers with the Internet Printing Protocol (IPP), originally standardized in 1999 but significantly enhanced for remote management through IPP Everywhere, which enabled driverless job submission over IP networks.[22] This allowed centralized driver updates and secure remote printing, where print servers handle device-specific rendering, minimizing local installations and supporting hybrid cloud environments for distributed fleets.[23] Mobile and wireless printing support emerged prominently with Apple's AirPrint in 2010, which facilitated driverless printing from iOS devices over Wi-Fi by using standardized IPP extensions, automatically discovering compatible printers without additional software.[24] Complementing this, the Mopria Alliance's Print Service, launched in 2013, extended similar driverless capabilities to Android devices, certifying printers for seamless integration via Wi-Fi Direct and enabling print jobs from smartphones and tablets without proprietary apps.[25] Security enhancements in printer drivers post-2010 addressed rising vulnerabilities through features like mandatory driver signing and encrypted data transmission. Microsoft implemented kernel-mode code signing requirements starting with Windows Vista, ensuring only verified drivers could load to prevent malware injection, a policy strengthened in subsequent updates.[26] Protocols such as IPP over HTTPS provided end-to-end encryption for print data in transit, mitigating interception risks in networked environments. The 2021 PrintNightmare vulnerability (CVE-2021-34527) in the Windows Print Spooler highlighted these needs, allowing remote code execution via driver installation flaws, prompting Microsoft to enforce administrator-only driver installs via out-of-band patches.[27][28] Sustainability features in drivers gained traction in the mid-2010s, with algorithms optimizing resource use through automatic duplexing and eco-modes that reduced ink or toner consumption by up to 50% in draft settings. These modes, embedded in manufacturer drivers like those from HP and Brother, dynamically adjusted print density and enabled default two-sided printing to minimize paper waste, aligning with energy efficiency standards such as Energy Star.[29][30]Types of Printer Drivers
Device-Independent Converters
Device-independent converters transform application-generated print data into intermediate, hardware-agnostic formats such as PostScript Level 3 or PDF, enabling subsequent interpretation by printers or additional software without reliance on specific device capabilities.[31] These converters operate by interpreting high-level page description languages (PDLs) that describe document layout, graphics, and text in a resolution- and device-independent manner, allowing the output to be processed uniformly across diverse hardware.[32] A primary advantage of device-independent converters is their promotion of portability, reducing the necessity for bespoke drivers tailored to individual printer models and facilitating consistent output quality across devices.[33] They also support advanced workflows, such as previewing print jobs on screen or editing content before final rendering, which enhances user control and efficiency in document preparation.[34] Prominent examples include Ghostscript, an open-source interpreter first developed in 1988, which rasterizes PostScript files into bitmaps or other formats and underpins many PDF viewers and virtual printers.[35] Another is the Adobe PDF converter, which leverages PostScript-derived technology to generate portable PDF files from print streams. These converters excel in use cases like virtual printing, where documents are output as editable PDFs for digital distribution, or in networked environments where jobs are routed to print servers for device-specific finalization.[36] They are particularly valuable in graphic design and publishing, ensuring device-independent color accuracy and layout fidelity during proofing stages.[37] However, device-independent converters can introduce limitations by forgoing hardware-specific optimizations, such as proprietary color management or efficient rasterization tailored to a printer's engine, potentially resulting in suboptimal performance or quality on specialized devices.[38] In contrast to device-specific converters, they prioritize abstraction over model-targeted efficiency.[33]Device-Specific Converters
Device-specific converters are printer drivers tailored to individual printer models or families, responsible for translating generic page description languages (PDLs) such as PostScript or PDF into the proprietary command sets required by the printer's firmware. This mapping process ensures that abstract print data is rendered directly into hardware-optimized instructions, enabling precise control over the printer's internal processing. For instance, Hewlett-Packard's PCL XL, a vector-based PDL, converts graphical elements into scalable commands that the printer's engine can execute efficiently for high-quality output on LaserJet models.[39] Similarly, Epson's ESC/P-R command set handles raster graphics by sending pixel-level directives suited to inkjet mechanisms, optimizing ink droplet placement and color layering.[18] Canon's UFR II (Ultra Fast Rendering II) performs host-side rendering to generate model-specific bitmaps or commands, incorporating printer hardware details for streamlined data transfer.[40] These converters offer significant advantages by exploiting printer-specific hardware capabilities that universal drivers cannot fully access. They enable high-speed rendering through direct firmware integration, reducing latency in complex jobs like vector-to-raster conversion on the device itself.[41] Advanced finishing options, such as automatic stapling, hole-punching, or booklet creation, are activated via proprietary commands that interface with the printer's mechanical subsystems, ensuring reliable execution without software intermediaries.[42] In laser printers, Canon UFR II drivers support model-specific color management to achieve precise output, including manual adjustments for color balance.[43] Development of device-specific converters is typically handled by the printer manufacturers, who leverage proprietary hardware specifications to build the translation logic. This involves accessing internal firmware documentation and testing against the printer's engine to map PDL elements to exact command sequences, often using software development kits (SDKs) provided internally.[42] While third-party developers may resort to reverse-engineering captured print streams or disassembling firmware for compatibility, official drivers rely on direct specs to ensure stability and feature completeness.[44] A key drawback of device-specific converters is the rapid proliferation of versions tied to printer generations, which exacerbates compatibility issues in mixed environments or during OS upgrades. Each model variant may require a unique driver update, leading to fragmentation where older drivers fail on new systems due to architecture mismatches, such as 32-bit to 64-bit transitions, potentially causing print failures or lost features.[45] This model-bound approach also complicates deployment in enterprise settings, as administrators must maintain extensive driver libraries to avoid conflicts across fleets.[46]Operating System Implementations
Unix and Unix-like Systems
In Unix-like systems, the Common Unix Printing System (CUPS), introduced in 1999, serves as the standard print spooler and management framework, enabling modular and extensible printer driver architectures.[47] CUPS processes print jobs through a pipeline that includes filters and backends, with PostScript Printer Description (PPD) files providing device-specific configuration for features like paper sizes, resolutions, and color options.[48] This open-source design promotes interoperability across diverse hardware by separating driver logic into reusable components, such as rasterization filters and network backends.[49] Printer drivers in these environments often leverage the Foomatic database, a comprehensive repository developed in the late 1990s, to generate customized filters that convert document formats into printer-compatible data.[50] Foomatic integrates with CUPS by producing PPD-based configurations and supports Ghostscript, an interpreter for emulating PostScript on non-PostScript printers, allowing broader compatibility for legacy and raster-based devices.[51] This approach adapts general device-specific converters by chaining filters—such as Ghostscript for PostScript rendering followed by vendor-specific raster drivers—to handle complex printing pipelines.[52] Key administrative tools enhance CUPS's modularity and network focus; for instance, lpadmin configures printer queues by associating PPD files with backends for local or remote devices.[53] Avahi implements zero-configuration networking via mDNS/DNS-SD protocols, enabling automatic discovery and advertisement of printers on local networks without manual IP addressing.[54] Additionally, Samba facilitates cross-platform sharing by exposing CUPS queues over SMB/CIFS, allowing Unix-like systems to serve print jobs to Windows clients seamlessly.[55] Modern advancements include IPP Everywhere, a standard ratified in the 2010s by the Printer Working Group, which enables driverless printing on Linux and macOS by relying on standardized IPP attributes for job submission and device capabilities.[56] CUPS implements this through built-in support for IPP/2.0, allowing clients to query printers directly for supported media, finishes, and formats without proprietary drivers.[57] A notable challenge in Unix-like printing arises from the reliance on community-maintained backends and filters for non-PostScript printers, where open-source projects like Foomatic and Ghostscript must continually update support for evolving hardware amid limited vendor contributions.[52] This dependency can lead to inconsistencies in compatibility for specialized or older raster printers, requiring ongoing collaboration from distributions and upstream developers.[9]Windows Systems
In Windows operating systems, printer drivers follow a layered architecture designed to abstract hardware specifics and ensure compatibility across diverse printing devices. The version 3 (V3) printer driver model, which served as the foundation for earlier Windows versions, relies on Graphics Device Interface (GDI) rendering and operates primarily in kernel mode, potentially exposing the system to stability risks from faulty drivers.[58] In contrast, the version 4 (V4) driver model, also known as Type 4 drivers, was introduced with Windows 8 and Server 2012 as a user-mode refinement of V3, emphasizing isolation and simplified development to mitigate crashes and reduce administrative overhead.[58] XPSDrv, launched in 2007 with Windows Vista, represents an intermediate XML Paper Specification (XPS)-based evolution within the V3 framework, enabling pipeline filters for enhanced rendering and feature processing without full kernel dependency.[21] Type 4 drivers further advance this by enforcing kernel-mode isolation, where rendering components run in isolated user-mode processes, preventing a single driver's failure from disrupting the print spooler or other system services.[59] Printer driver management in Windows leverages Plug and Play (PnP) detection, where information (INF) files define device hardware IDs and installation parameters to automatically identify and configure printers upon connection.[60] The Device Manager provides a centralized graphical interface for users and administrators to select, install, update, or troubleshoot drivers, integrating seamlessly with the Windows print subsystem for queue management and status monitoring.[61] Key features in modern Windows implementations include Universal Print, a cloud-based service announced in 2019, which virtualizes printer access through Microsoft Azure, eliminating the need for local driver installations on client devices by routing jobs via a connector on-premises or in the cloud.[62] Additionally, Windows supports Mopria-certified devices through Windows Protected Print Mode, which enables driverless printing using the modern print stack and the Microsoft IPP Class Driver, allowing seamless integration via standardized Internet Printing Protocol (IPP) extensions without custom third-party driver installations.[63] Microsoft is transitioning away from legacy third-party printer drivers (V3 and V4) toward this modern, secure print platform centered on the IPP Class Driver for Mopria-certified printers. This shift enhances security by mitigating over half of past reported printing vulnerabilities, simplifies management by eliminating third-party drivers, reduces support costs, and ensures consistent printing across devices.[64][65] Key timelines in this transition include:- January 15, 2026: No new third-party printer drivers published to Windows Update for Windows 11 and later, and Windows Server 2025 and later.
- July 1, 2026: Windows prefers the IPP inbox class driver in printer ranking.
- July 1, 2027: Third-party driver updates limited to security fixes only.[65]