Stirling-PDF 於十一月五日發布 3.3.0 版，這個累積九萬五千七百八十七顆星標的開源 PDF 平台，把 Office 轉檔核心從 LibreOffice 換成自家引擎。官方同時公布時間表，下週預設啟用新引擎，再下一週移除 LibreOffice 與相關依賴。
Stirling-PDF 3.3.0 是什麼？
Stirling-PDF 是 GitHub 星標最多的開源 PDF 平台，內建五十多種工具。3.3.0 版於十一月五日發布，主軸是替換轉檔引擎。
此版本的定位相當明確。此次更新處理的是底層依賴，把長年捆綁的辦公室文件轉檔元件逐步換走。
專案在 README 中以「開源 PDF 平台」定位自己，支援桌面客戶端、瀏覽器介面與自架伺服器三種形態，介面提供四十多種語言。3.3.0 版的改動集中在轉檔引擎、記憶體佔用、行動掃描與安全修補四個方向。
Office 轉檔為什麼要脫離 LibreOffice？
LibreOffice 體積龐大，無介面環境轉檔易現字型與版面偏差。專案改以自研 Office Convert 處理，計劃兩週內完全移除對它的依賴。
長期以來，多數自架 PDF 工具處理 Word、Excel 與 PowerPoint 的方式，都是呼叫 LibreOffice 的無介面模式。這條路徑可靠，但代價是可觀的映像體積與啟動延遲，字型缺失時版面亦容易走位。
3.3.0 版把 Office Convert 升級至 0.3.3，並擴大它的適用範圍。使用者現在可以在電子郵件轉 PDF、HTML 轉 PDF、Markdown 轉 PDF 與電子書轉 PDF 等工具中選用它，反向的 PDF 轉 HTML、Markdown、XML、EPUB 與 AZW3 亦可指定同一引擎，PDF/A 封存格式同樣納入。
官方在版本說明中直接寫出時間表。下週會把 Office Convert 設為預設引擎，若期間沒有出現必須修正的問題，再下一週便會移除 LibreOffice 與其他相關依賴。團隊同時邀請使用者比對新舊引擎的輸出，並附上範例檔案回報差異。
3.3.0 版在效能與檔案處理上有哪些改動？
此版把 JPDFium 升至 1.3.0 並加入 Windows ARM64 支援，遮罩與合併分割更準確，處理大檔時記憶體佔用下降，後端另導入二級快取。
核心依賴的升級是這版技術含量最高的一環。JPDFium 升至 1.3.0 後，遮蔽敏感內容的操作精度提升，合併與分割在處理複雜頁面時更為穩定，開啟大型檔案的記憶體峰值同時下降。
伺服器端的改動則針對資料庫壓力。專案為核心實體導入 Hibernate 二級快取，使用 Caffeine JCache 實作，並減少已認證請求路徑上重複的使用者查詢，官方描述為資料庫讀取次數大幅減少、請求回應更快。
其餘項目偏向維運體驗。啟動與執行時期的日誌被調低至較安靜的等級，Spring Boot 升至 4.1.2，Docker 基礎映像與多項相依套件同步更新。
手機掃描功能移除 OpenCV 後有什麼變化？
專案以內建頁面偵測取代原本捆綁的 OpenCV，移除約 9MB 負載。官方表示掃描速度與邊緣偵測準確度同時提升，容器映像體積亦因此縮小。
舊版在行動裝置掃描流程中捆綁 OpenCV，用於偵測紙張邊界與校正透視。這個做法效果穩定，但為了一個功能而引入近 9MB 的原生函式庫，對容器映像與啟動時間都不划算。
3.3.0 版改用專案自行實作的頁面偵測邏輯，移除 OpenCV 依賴。版本說明提到掃描更快、更準確，同時保留下述安全強化：伺服器端限制請求大小，並對行動掃描的中繼服務加入防護。
這條改動與 Office Convert 的方向一致。專案正在系統性地削減第三方原生依賴，把體積與行為的控制權收回自己手上。
SSO 自動登入與安全修正解決了哪些問題？
舊版啟用密碼登入後，SSO 自動登入便失效。此版讓兩者並存，管理員仍可經 /login?all 進入密碼表單，另修補重新命名繞過與多因素驗證保護。
企業部署最常遇到的取捨，是單一登入與本機帳號能否共存的問題。過去一旦開啟密碼登入表單，SSO 的自動登入流程便會被打斷，管理員只能二選一。
3.3.0 版把兩條路徑並行處理。使用者透過 SSO 進入時可自動完成登入，需要本機帳號的管理員則可經由 /login?all 進入密碼表單，兩種驗證方式不再互斥。
安全層面共有三項值得留意的修正。重新命名的檢查改為不分大小寫，避免以大寫變體繞過副檔名限制；多因素驗證設定加上保護；單次邀請碼改為與帳號建立在同一交易中原子性消耗。此外，憑證簽署現在接受未加密的 PKCS#8 PEM 私鑰，PDF/UA 字型嵌入亦不再令表單欄位失去可填寫狀態。
Stirling-PDF 的技術數據表現如何？
專案現有九萬五千七百八十七顆星標、九千九百九十九個分支、五百零五個待處理議題，語言以 TypeScript 為主，二零二三年一月建立，採開放核心授權。
星標的增長速度是觀察此類工具的重要指標。八月十六日該專案為八萬九千五百五十四顆星標，三個月後增至九萬五千七百八十七顆，平均每月約增加二千顆。
專案的語言組成值得說明。早期以 Java 撰寫後端，主語言標記現已顯示為 TypeScript，反映前端與桌面客戶端的比重上升。
授權採開放核心模式，社群版可免費自架，企業功能如單一登入與稽核紀錄則另行提供。Docker 映像為主要部署方式，官方指令為單行啟動並對外開放 8080 連接埠。
自行部署 Stirling-PDF 需要注意什麼？
若既有腳本依賴舊版後端文字編輯 API，升級後會直接失效。此外 LibreOffice 將在兩週內退出，混用新舊轉檔路徑的流程需預先測試輸出結果。
第一個風險是介面移除。版本說明明確指出，已棄用的後端 PDF 文字編輯 API 在此版刪除，官方表示新的文字編輯 API 仍在規劃中。任何透過此介面批次修改 PDF 內容的腳本，升級後都會中斷。
第二個風險是轉檔路徑改變。若團隊習慣以 LibreOffice 處理特定格式，建議先在測試環境比對 Office Convert 的輸出，特別是含複雜表格、特殊字型與圖層的文件。
第三個風險與企業功能相關。此版調整了訪客帳號的權限邊界，儲存至伺服器與分享控制對訪客隱藏，單一登入的行為亦有變動，設定前宜先確認既有權限設計。
出處連結有哪些？
原始碼與版本說明可在 GitHub 的 Stirling-Tools/Stirling-PDF 查閱，3.3.0 版於十一月五日發佈，完整清單見該版本頁面。
專案的程式碼、問題追蹤與版本發佈集中在 GitHub 的 Stirling-Tools 組織之下。完整安裝選項涵蓋桌面應用、Docker、Kubernetes 與私有 API 部署，文件另設獨立站點。
參考來源：https://github.com/Stirling-Tools/Stirling-PDF
總結：Stirling-PDF 適合什麼團隊？
需要在不外傳文件前提下批次處理 PDF 的團隊最為適合，特別是具備容器部署能力的資訊部門。若流程依賴 LibreOffice 特有行為，宜待新介面推出後再升級。
3.3.0 版的意義不在功能數量，而在依賴結構的調整。把辦公室文件轉檔與影像處理兩條第三方原生依賴換成自研實作後，容器映像更小、行為更可預測，升級路徑亦更容易掌握。
代價是相容性風險集中於過渡期。官方給出的時間表相當緊湊，從預設啟用到移除 LibreOffice 只隔一週，對格式要求嚴格的組織而言，緩衝時間有限。
對於以文件處理為日常業務的團隊，此版的價值在於可稽核與可自控。文件全程留在自有基礎設施之內，轉檔行為由單一引擎決定，排查問題時不必再在兩套技術堆疊之間來回。
