再增加一种打印机驱动程序，价值已经退居其次。打印软件近年来最实用的新抽象，是把打印机呈现为一项服务。

在当前的 Linux 系统中，打印对话框里的目的地可以来自三种截然不同的途径。有些网络打印机直接使用 IPP Everywhere；USB 多功能设备可在 localhost 上由 ipp-usb 映射出来；较旧或用途特殊的打印机则可置于 Printer Application（打印机应用程序）之后，由它把现代 IPP 请求翻译成硬件仍能理解的语言。对于应用程序和操作系统的大部分组件而言，三者看起来都是可发现的 IPP 目的地。

这种汇合处在 OpenPrinting 漫长转型的中心。旧式软件栈会在主机的打印系统中安装型号描述文件和能够运行的转换过滤器。正在成形的新式软件栈会查询目的地具备哪些能力，提交标准文档，再通过同一协议接收状态。由此划出的边界更为清晰，适合沙箱化桌面、不可变操作系统、混合客户端群，也能让仍有使用价值的硬件摆脱原有驱动程序包设定的年限。

这张图谱尚未完全成为现实。OpenPrinting 目前将 CUPS 2.4.19 列为最新版本，而项目的 3.x 规划描述了一套未来的全 IPP 架构，其中本地服务与共享服务相互分离。[10][7] 运维人员因此需要同时掌握两条路线：维护各 Linux 发行版当下采用的 2.4 系统，同时不再增添对 PPD 与过滤器模式的新依赖，因为 3.x 的设计目标正是让这套模式退出核心系统。

图片说明：封面呈现两台维修中的旧 HP LaserJet，画面焦点落在实体设备上，并未采用泛化的云或协议图形。它契合本文，是因为 OpenPrinting 转型归根结底关乎一件实际的事：让实体机器继续可用，同时让操作系统摆脱每一种旧驱动程序的束缚。照片本身无法说明这两个型号是否支持 IPP Everywhere 或某个特定的 Printer Application；兼容性仍须逐一核对型号。[3][12]

从共同约定讲起

CUPS 2.x 以调度器为核心。它接收 HTTP 和 IPP 请求，管理打印机与类别，安排作业队列，报告状态，并分派送达设备所需的工作。在经典设计中，提交的文件会经过一个或多个过滤器，转换成可打印格式，随后由后端通过 USB、IPP、LPD、SMB 或其他传输方式把结果发送出去。[1]

面对种类繁多的打印机语言和连接方式，这套架构为 Linux 提供了统一的打印入口。一篇独立文章回顾 CUPS 1.6 转型时，记录了调度器周围累积的繁重职责：网络发现、作业排队、PDF 或 PostScript 转换、光栅化、页面变换、设备后端，以及向 Gutenprint 等项目移交任务。Apple 从 CUPS 中移除面向 Linux 的过滤器后，OpenPrinting 将其延续为独立的 cups-filters 项目。[9]

IPP Everywhere 改变了约定所在的位置。符合规范的打印机会通过 DNS Service Discovery 发布自身，响应有关能力与状态的 IPP 查询，并接受标准化的作业格式。Printer Working Group 指出，基线要求包括 IPP/2.0、DNS-SD、PWG Raster，彩色设备还须支持 JPEG；建议能力则包括 PDF 和 IPP-over-USB。其当前概览称，售出的打印机中有 98% 支持 IPP/2.0 和 DNS-SD。[2]

因此，“无驱动”是一种简写，其中没有魔法。打印机里仍有固件，主机上仍有发现软件、CUPS 客户端以及通常存在的调度器，同时还涉及文档处理、身份验证、网络策略和用户界面。消失的是在每个客户端操作系统里安装厂商专用或型号专用驱动程序二进制文件的要求。打印机由此成为一项可查询的服务，不再是一个只能依靠本地文件复原其能力的沉默盒子。

原生 IPP 打印机：设备自行描述能力

最短的路线从一台接入以太网或 Wi-Fi 的打印机开始，它已经实现 IPP Everywhere、AirPrint 或兼容的无驱动配置规范。CUPS 发现这项服务，查询支持的介质、彩色模式、双面打印行为、分辨率和文档格式等属性，随后将作业提交到其 IPP URI。状态也能通过同一模型返回，不再依赖静态 PPD 进行推测。

这里的改变超出了安装便利性。PPD 记载的是驱动程序作者认定某个型号具备的能力。IPP 属性则能呈现设备此刻的状态，包括已装载介质、当前可用格式、装订与收尾功能、耗材状态和作业状态原因。OpenPrinting 指出，这种动态状态正是经典 PPD 与驱动程序接口越来越难以适配现代硬件的原因之一。[3]

这道边界依然存在故障方式：发现服务会失灵，此时打印机仍可访问；设备会宣告一种由固件错误处理的格式；打印对话框会漏掉 IPP 响应中已有的属性；地址或网络变更后，队列也会指向错误的 URI。“打印机已经出现”和“文档已经正确渲染”属于两项独立测试。

这种分离有助于诊断。Fedora 的打印指南要求用户分别在发现与连接（avahi、libusb、后端或 cups-browsed）、访问策略、文档过滤器、PPD 处理、固件和硬件等环节定位故障，不能把每一种症状都视为同一个 CUPS 故障。[8] 在以 IPP 为先的设备群中，同样的排查次序会更加清楚：先验证可达性和已宣告能力，再验证作业创建，随后检查渲染与设备输出。

USB 设备：本地线缆转化为本地服务

USB 看似是网络服务设计中的例外，ipp-usb 则有意消除了这个例外。对于实现 IPP-over-USB 的设备，该守护进程会在本地网络套接字上公开打印机的 IPP 服务，通过 DNS-SD 在 localhost 上发布服务，并让 CUPS 像访问无驱动网络目的地一样与它通信。对于多功能设备，同一座桥接还能提供 eSCL 或“AirScan”扫描。[4]

这是一种架构上的归一化，USB 打印机仍应留在本地范围。线缆和设备都在本机，软件界面则改用 HTTP 与 IPP。打印对话框、CUPS 和扫描前端因而可以使用相同的发现与能力描述语言，无论数据包最终穿过 Wi-Fi 还是 USB 控制器。

每一层也因此拥有可观察的故障边界。ipp-usb 若无法占用或识别设备，IPP 目的地就不会出现。目的地若已出现在 lpstat -e 中、应用程序却看不到它，问题便落在桌面集成上。ipptool 若返回某项属性、队列却将其漏掉，则应检查 CUPS 的转换环节。与 USB 作业一停滞就重新安装所有打印机软件包相比，这样的定位精确得多。[4][8]

Printer Application：旧式翻译程序获得了地址

面对较旧和专业用途硬件，这张图谱开始显出复杂性。OpenPrinting 在 2018 年随 CUPS 2.2 弃用原始队列，又在 2019 年随 CUPS 2.3 弃用经典打印机驱动程序，但已安装的打印机当然不会瞬间学会 IPP。为此，项目定义了 Printer Application：这类守护进程在一端呈现 IPP/2.0 打印机服务，在另一端使用现有驱动程序、过滤器或打印机原生语言。[3]

PAPPL 为这种模式提供框架。它可以接收 JPEG、PNG、PWG Raster、Apple Raster 或原始作业，提供嵌入式 IPP Everywhere 服务，并通过 USB 或 AppSocket/JetDirect 向设备发送输出。OpenPrinting 已用它开发出覆盖 PostScript、基于 Ghostscript 的驱动程序、HPLIP、Gutenprint、标签打印机及其他产品家族的应用程序。[5][3]

这一变化细微，却会带来深远影响。经典驱动程序装入主机打印管线，并受其文件布局、执行环境、架构和软件包生命周期约束。Printer Application 则在协议边界之后自行管理翻译工作，可以独立打包和更新；沙箱化客户端的权限范围止于访问 IPP 端点，型号专用过滤器链交由服务端处理。

这套办法仍有明确的支持范围。OpenPrinting 的兼容性表列出了已知空白，包括 Canon CAPT 和 UFRII 产品家族，以及部分 Pantum GDI 设备；对这些设备，项目建议用户联系制造商。[3] Printer Application 本身也是软件，照样会崩溃、错误渲染、失去 USB 访问权，或把服务暴露到过宽的范围。它带来的收益是一道易于辨认的组件边界，维护工作依然存在。

cups-filters 的拆分有明确用意

配套库展示了 OpenPrinting 如何在保留实用转换工作的同时，逐步淘汰旧有设定。第二代 cups-filters 将原来的整套组件拆成几个独立部分：libcupsfilters 包含不支持 PPD 的转换函数；libppd 单独收纳旧式 PPD API；cups-filters 程序服务于 CUPS 2.x；cups-browsed 则管理发现的打印机与远程队列。Printer Application 可以复用转换库，并在确有需要时调用被隔离的旧式层。[6]

这套拆分浓缩了整张生态图谱。CUPS 管理作业与目的地的语义；PWG 标准定义共用协议；打印机固件可以直接实现目的地；ipp-usb 负责适配物理传输方式；PAPPL 将旧式翻译代码包装成目的地；libcupsfilters 保留文档转换能力，同时让未来的核心系统摆脱 PPD；桌面项目则决定用户能否真正看见并控制这些组件公开的功能。

拆分还保留了一条退出路线。随着原生 IPP 硬件替代某类设备，对应的 Printer Application 与 libppd 依赖即可退出，而其他组件所需的 PDF、光栅、色彩或版面功能仍能保留。OpenPrinting 称，这正是将全部 PPD 支持集中到独立项目的原因：旧式层日后可以停止维护，其余部分则继续发展。[6]

CUPS 3.x 同时收窄权限与职责范围

OpenPrinting 的 3.x 规划不止于删除驱动程序 API。它将当前守护进程拆成两项服务：本地服务器以非特权用户身份运行，处理该用户的打印任务；系统共享服务器则负责向网络发布队列。规划中的两者都是基于 PAPPL 构建的 IPP 目的地。库会增加配套 API，调度器则不再容纳经典驱动程序和 PPD。[7]

这项拆分对应两类不同的信任问题。把本地用户的文档发送到附近打印机，本身不要求使用 root 身份的网络服务。在整栋建筑内共享队列，则需要持久的策略、身份管理、可达性和运维。两种职责分开以后，需要跨越权限边界的代码与状态随之减少。

仅靠拓扑拆分仍无法保障打印安全。CUPS 文档说明，其独立运行的默认配置会拒绝远程连接；一旦启用共享或远程管理，普通互联网服务所面对的风险也会随之出现，包括未经授权的访问，以及通过大型或重复作业实施的拒绝服务攻击。[11] PAPPL Printer Application 同样可以开放本地或网络访问。[5] 运维人员仍须审慎设置监听地址、防火墙规则、身份验证、加密、补丁、日志和责任归属。

当前版本状况要求迁移分阶段进行。CUPS 2.4.19 仍是已发布的最新版本，各发行版也要等到 3.x 库、本地服务、共享服务、软件包集成和桌面控制功能全部就绪后才会迁移。[10][7] 合理的做法是修补并摸清现有 2.4 设备群，同时让每一次新硬件与软件选择都减少对经典驱动程序的依赖。

设备群清点以目的地为准

一份实用的清单应当按照每台实体设备能够提供的服务分类：

1. 原生 IPP 目的地。 记录准确的 URI、固件版本、宣告的格式、介质、双面打印与装订收尾属性，并验证发现服务在实际 VLAN 与防火墙布局中能否持续工作。
2. IPP-over-USB 目的地。 验证 ipp-usb 已接管设备，lpstat -e 能看到本地服务，并分别测试打印与扫描功能。
3. Printer Application 目的地。 将准确型号和当前驱动程序匹配到仍在维护的应用程序，再记录由谁为守护进程打补丁、其状态存放何处，以及客户端如何发现它。
4. 不受支持的旧式目的地。 在经过测试的替代方案出现以前，将仍可工作的 CUPS 2.x 路线隔离保存，并确保可以恢复。路线图本身充当不了驱动程序。

针对每一类设备，都要打印一组规模不大但足以暴露问题的材料：文本、矢量 PDF、光栅图像、混合页面方向、双面文档、实际使用的信封或标签尺寸，以及组织为之付费的所有装订收尾操作。比较实体输出，不能只看队列是否完成。把 IPP 属性和日志与纸面结果一同留存。某个型号宣告的 PDF 路径若会破坏真实文档，受控的光栅规避方案有时比理论上的纯粹性更可靠。

只有一台现代打印机的小型团队，通常可以把这套软件栈的大部分工作交给发行版默认配置。学校、办公室、实验室和大量打印的机构则需要为发现服务、队列策略、旧式翻译、固件和回滚明确负责人。系统的模块化程度提高后，职责会更加清楚，具体责任仍需有人承担。

最终收益是持久的互操作性。文档生成程序不再需要熟悉每一种打印机型号，旧式翻译程序也不再需要驻留于调度器内部。网络、USB 与模拟出的目的地可以汇聚到同一套可检查的约定上。OpenPrinting 的押注在于，当每条通往纸面的路线都先学会以服务的方式运作，Linux 打印就能更从容地演进。

来源

1. OpenPrinting，“CUPS 设计说明”——CUPS 2.x 调度器、HTTP/IPP 请求路径、配置状态、过滤器与后端。
2. Printer Working Group，“IPP Everywhere”——发现、协议、文档格式、能力与自认证所需的基线。
3. OpenPrinting，“Printer Application 与打印机驱动程序”——原始队列和驱动程序的弃用、PPD 的局限、Printer Application 模型与当前兼容性表。
4. OpenPrinting，“ipp-usb”——localhost IPP 桥接、DNS-SD 发现、并行 HTTP 处理与通过 USB 提供的 eSCL 扫描。
5. Michael R. Sweet，pappl 代码库——框架范围、嵌入式 IPP Everywhere 服务、支持的作业格式、传输方式、要求与当前版本更新情况。
6. Till Kamppeter，“cups-filters 第二代——首个 Beta 版本”（2022）——libcupsfilters、libppd、CUPS 2.x 程序与 cups-browsed 的拆分。
7. Till Kamppeter，“全职投身自由/开源软件打印工作的 25 年”（2025）——OpenPrinting 的历史，以及 CUPS 3.x 本地服务器、共享服务器、全 IPP、软件打包和桌面集成规划。
8. Fedora Project，“如何调试打印问题”——一套独立的运维分类，涵盖发现、访问、过滤器、驱动程序、固件、队列、Printer Application 与 IPP-over-USB。
9. Nathan Willis，“CUPS 1.6 正在重塑 Linux 打印”，LWN.net，2012——关于客户端/服务器工作流，以及 OpenPrinting 接手面向 Linux 过滤器的独立历史记录。
10. OpenPrinting，CUPS v2.4.19 版本——当前发布版本线与共享打印回归问题的修复。
11. OpenPrinting，“服务器安全”——独立运行时的默认暴露范围，以及启用共享后出现的访问、保密与拒绝服务边界。
12. Nenad Stojkovic，“HP LaserJet 3015 and 2035”（2020），Wikimedia Commons——两台维修中旧打印机的纪实照片，用作本文图片。