開源列印補上的 4 個缺口

開源列印這次補的是列印從電腦到設備之間最容易斷線的中段，OpenPrinting 在 2026-07-26 公布 11 個 Google Summer of Code 2026 專案，主題集中在 CUPS 3.x、PDFio、CI、fuzz testing、印表機與掃描器模擬、local ML driver lookup

OpenPrinting（以 Linux Foundation 子組織身分參與 GSoC 的開源列印專案群，維護 Linux/Unix 列印工具與資料）這波進度，我會把它翻成一句現場話：電腦找不找得到機器、PDF 會不會被正確拆成可印資料、更新後會不會壞在客戶端

Google Summer of Code（Google 的開源實作計畫，讓貢獻者在導師帶領下完成程式專案）通常看起來很工程，但印刷採購要看的是風險位置。列印問題很少只壞在一個點，常是檔案、driver、作業系統、設備韌體互相推責任。開源列印正在補的，就是這些責任邊界

CUPS 3.x 會影響採購，因為它把列印管理推向 IPP print destinations 與 Printer Applications，傳統 PPD driver 的安裝邏輯會慢慢退到後面

CUPS（Common Unix Printing System，Unix/Linux 常用列印系統，負責接收、排隊、套用選項與送出列印工作）是很多 Linux 列印流程的總機。IPP（Internet Printing Protocol，網路列印通訊標準，讓電腦用共同語言找設備、查能力、送工作）則像設備溝通用的公版話術

OpenPrinting 提到 KDE Print Manager 正在同時處理 CUPS 2.x 與 CUPS 3.x，並把測試拆成可依版本選路的方式。另一個 CI 專案則把 libppd、libpappl-retrofit、libcupsfilters、cups-filters、cups-snap 放進自動測試，涵蓋 CUPS 2.4.x、2.5.x、3.x/libcups3 與 4 種架構

採購時別只問「可不可以印」。要問設備是否支援 driverless IPP、舊機是否需要 Printer Application、管理頁能不能看到狀態、未來作業系統升級後誰負責驗證。這幾題問完，報價單會安靜很多

PDF renderer 補的是把 PDF 變成設備可吃的 raster，fuzz testing 補的是在壞檔、怪檔與邊界格式進來前先把程式撞過一輪

PDFio（Michael Sweet 維護的 PDF 函式庫，讓程式讀寫 PDF 結構）正在被延伸成 permissive license 的 PDF renderer。這件事對一般人很白話：PDF 看起來正常，不代表印表機能直接理解 PDF 裡的字型、圖片、頁面邊界與解析度，renderer 要把 PDF 拆成像素資料再交給設備

素材裡的 PDFio renderer 已做到 target DPI scaling、page boundary constraints、/XObject resource mapping，也用 FreeType 讀 /FontFile2 TrueType 字型，字型壞掉或缺漏時退到 DejaVuSans.ttf。行內人看到這裡會皺眉，因為字距一跑掉，客戶看到的不是技術債，是成品歪了

fuzz testing（用大量異常輸入反覆餵程式，找出崩潰與安全漏洞的測試方法）也在補風險。OpenPrinting 的 cups-filters fuzzing 專案用 AFL++、Honggfuzz、OSS-Fuzz-Gen，把 1,079 個 raw crashes 整理成 22 個可處理的 unique clusters。這種測試不浪漫，但很接近印刷現場每天收到怪 PDF 的真相

沒有實體設備也能測一部分列印流程，OpenPrinting 的 go-mfp 專案正把虛擬印表機、CUPS queue 與影像比對接成可自動跑的測試流程

CI（Continuous Integration，程式每次變更就自動建置與測試的流程）對印刷廠的意思很簡單：更新前先讓系統自己跑一輪，別等客戶急件進來才發現 queue 掛了。OpenPrinting 的 full print system testing pipeline 會載入 virtual printer model、建立 CUPS queue、列舉 print modes、送出 print jobs、擷取輸出，再用 SSIM、PSNR 這類影像指標比對結果

go-mfp（OpenPrinting 的 Go toolkit，用來模擬與測試多功能印表機）在 Phase 1 修了 3 個 IPP attribute-decoding bugs，Phase 2 用 embedded CPython 啟動 IPP server over TCP，再用 lpadmin 註冊 queue、用 lp 送出測試 PNG。很簡單，先在軟體裡摔過，實機上線才不會每次都靠師傅熬夜救火

掃描端也在補。IPP-Scan 是 Printer Working Group 5100.17 定義的 driverless scanning over IPP 標準，OpenPrinting 的 go-mfp 正在加入 client 與 server。對有掃描、列印、歸檔流程的公司，這代表未來可以把「掃得到」也放進同一套驗收語言

中小印刷廠現在該做的是把開源列印名詞改成驗收清單，先管相容、再管測試、最後管責任切分

我會用「麥思印刷（MS，中高階全客製商業印刷）送印三道關」處理新設備或新流程：

・① 檔案關：PDF 頁面大小、出血、字型嵌入、解析度與色彩模式先驗一次

・② 設備關：確認設備支援 IPP、是否靠 Printer Application、管理頁能不能查狀態

・③ 測試關：留一份標準測試檔，記錄 CUPS 版本、driver、queue 名稱與錯誤訊息

第一次做高規型錄、特殊紙或品牌提案，我會建議先找 麥思印刷 把檔案責任切清楚；只是名片、貼紙、小量 DM，可以走 麥印刷 先把規格下對

對設計師來說，開源列印補的是送印前的可預測性。對印刷廠來說，開源列印補的是 IT 和產線共用的檢查語言。對採購來說，開源列印補的是問問題的能力，別只看機器規格表，看更新後誰能證明它還能穩定出紙

・開源列印這波補在中段責任：設備要找得到、檔案要印得出、錯誤要追得到

・CUPS 3.x 採購問題很實在：新機要會 driverless，舊機要知道靠哪個 Printer Application

・PDF renderer 和 fuzz testing 把壞檔提早攤開，比上機後才退件省事

・中小廠先建立測試檔與版本紀錄，IT 和產線才會講同一件事

印刷製造端要把 CUPS、IPP、Printer Application 寫進設備驗收表；設計端要把 PDF 預檢當成送印前的固定動作；AI 導入不要只看生成草稿，要能檢查出血、字型、解析度與色彩模式；SaaS 團隊若要服務印刷流程，先把 queue 狀態、錯誤紀錄、檔案版本與設備能力做成可查的欄位，這會比多做一個漂亮上傳頁更有用

・OpenPrinting 2026 GSoC 開發近況