何時不該使用 NextPDF

Spec Spec: ISO/IEC 25010, §3.26 ISO/IEC 25010 §3.26 Spec Spec: ISO 24495-1 ISO 24495-1 Evidence ¶ Editorial Evidence: Editorial

速覽

這正是供應商通常不會寫的一頁：說明哪些情況下 NextPDF 並非適合的工具，以及哪一類工具才適合。 它直白點名不適用的情境，讓你在這套引擎本來就該被排除時，能迅速把它排除。

這是一份誠實的邊界聲明，而不是把功能清單逐項加上「不」字。

為什麼這很重要

最昂貴的整合，就是你當初根本不該開始的那一個。 在評估階段把工具選對，代價很低。 一旦合約簽訂、管線進入生產環境後才修正，代價就非常高昂。

好的引擎會幫助你及早做出這個判斷。 軟體品質指引把這稱為適切性可辨識度：也就是能從文件與第一印象判斷某項產品是否符合你需求的能力（ Spec Spec: ISO/IEC 25010, §3.26 ISO/IEC 25010 §3.26 ）。 一頁只會說「是」的內容，等於刻意讓自己無法通過這項測試。 而這一頁會在「否」才是誠實答案時說「否」。

簡短版

如果遇到下列情況，請選用 NextPDF 以外的工具：

• 你需要逐像素忠實算繪任意的現代網頁——完整 CSS、網頁字型，以及由 JavaScript 驅動的版面配置。 那是瀏覽器的工作。
• 你需要對掃描或純影像的 PDF 進行 OCR 或重建成結構化文字。 那是 OCR/文件理解的問題，而不是產生問題。
• 你需要把符合性裁決（PDF/A、PDF/UA、PAdES）當作具權威性的答案。 NextPDF 產生意圖符合規範的結構；至於它是否真正符合，則由獨立的驗證器決定。
• 你的核心工作負載是對第三方 PDF 進行大量互動式編輯或塗黑，而不是產生或檢視它們。
• 你所在的執行環境低於受支援的 PHP 下限，且無法使用 backport 路徑。

每一種情況的癥結都在於類別，而非品質：適合的答案是另一種工具。

NextPDF 如何看待這件事

NextPDF 是一套 PHP 引擎，用來產生 PDF 2.0 文件，並檢視其中的結構事實。 它的設計——明確意圖、輸入快速失敗、行程內且具決定性——正是為這項工作調校。 誠實的邊界，出現在問題本質屬於完全不同形態的地方。

下表將每一種不適用的情況，對應到它為何形態不對，以及哪一類工具才適合。 表中不點名任何產品；重點是工具類別。

若你的問題是……	為何 NextPDF 形態不對	哪一種才適合
逐像素忠實算繪任意的現代網頁	行程內的 HTML/CSS 引擎針對的是明確且有文件記載的子集，以求可預期且具決定性的輸出——而非整個不斷演進、帶有腳本的網頁平台	真正的瀏覽器引擎（無頭瀏覽器算繪器），透過生態系中的瀏覽器橋接驅動
把掃描或純影像的 PDF 轉成結構化文字	NextPDF 不執行 OCR 或文件理解；它負責產生與結構檢視，並不把像素解讀成語意	專用的 OCR/文件理解管線；若你接著需要產生 PDF，再把它的輸出餵給 NextPDF
具權威性的符合性裁決	行程內檢查是必要而非充分的——依設計，它們回報的是結構事實，而不是 pass/fail 裁決	以獨立的驗證器（例如受認可的 PDF/A 或無障礙檢查器）作為關卡
把對任意 PDF 的大量互動式編輯/塗黑當作核心工作	此引擎為產生與結構檢視而最佳化，並非設計成可對不受信任的第三方檔案進行一般往返編輯的編輯器	專為 editing/redaction 工作流程打造的工具類別；produce/inspect 部分則交給 NextPDF
執行環境低於受支援的 PHP 下限	此引擎刻意建立在現代 PHP 語言特性之上	適用時走有文件記載的 backport 路徑；否則改用另一套工具鏈

反覆出現的主軸，是引擎對自身的誠實。 它行程內的符合性檢查在自己的輸出裡就這麼說：它們是必要而非充分的——乾淨的結果「並不確立 ISO 符合性」，而裁決「屬於獨立的驗證器」。 它的快速 PDF 檢視器對自己也是同樣的說法：它是「一種快速的結構分流，而非驗證器……它不驗證簽章、不解密內容，也不主張符合性。 請把結果當作路由的輸入，而非信任裁決。」 此引擎拒絕對自己誇大宣稱。 因此，一頁拒絕過度推銷它的內容，才會與此引擎保持一致。

有些邊界不是固定界線，而是版本能力之間的分界。 舉例來說，封存（PDF/A）的產生是更高層級的能力，而非缺漏的能力。 此引擎呈現的是可採取行動的升級路徑，而不是單純拒絕：

PDF/A archival production — edition availability

Edition	Availability
Core	○ 不在 Core 中——呼叫封存 API 會回傳可採取行動的訊息， 指出哪個套件可以啟用它，而不是以晦澀方式失敗。 純 PDF 2.0 輸出仍完全可用。
Pro	○ 可用——PDF/A 封存符合性產生屬於 Pro 層級能力。
Enterprise	○ 可用——隨更高層級一併提供。

因此，將 Core 解讀成「NextPDF 無法做封存」是錯的。 在正確的版本中它做得到，而且它會明確地告訴你，而不是用猜測或默默失敗來回應。 真正的邊界仍是前面那一條：符合性裁決在每一個版本中都永遠屬於獨立的驗證器。

Human-factors note: Human-factors note

把限制放在推銷話術之前，是刻意且有標準依據的選擇。 淺白語言指引明確指出，大多數讀者需要的資訊應排在只有部分人需要的資訊之前，而且警告應排在操作指示之前，而非之後 （ Spec Spec: ISO 24495-1, §5 ISO 24495-1 §5 ）。 對於進行工具選擇的資深工程師而言，「這裡哪裡不適用」正是你需要優先知道的資訊。 讀完它應該只要一分鐘，卻能為你省下大量時間。

證據怎麼說

本頁屬於 Evidence ¶ Editorial Evidence: Editorial ：它是一項經過推理的邊界判斷，而非程式碼或基準測試的主張，且如實標示為此類別。 有兩件事讓它不只是單純意見。

• 此引擎自身的產物也用自己的話承認同一點：符合性路徑自陳「必要而非充分」，並把裁決交由獨立的驗證器；快速檢視器自陳為「結構分流，而非驗證器」。 此處的邊界聲明與引擎對自己的描述一致，而非比它更高調。
• 陳述邊界的這項紀律，依據的是 Spec Spec: ISO/IEC 25010, §3.26 ISO/IEC 25010 §3.26 （適切性可辨識度——從文件判斷是否合適）與 Spec Spec: ISO 24495-1, §5 ISO 24495-1 §5 （優先呈現讀者需要的內容與警告）。

當某項邊界其實是程式碼層級的行為時——例如行程內符合性檢查不具權威性，或封存屬於版本能力——該行為會搭配 Evidence { } Code-backed Evidence: Code-backed 證據，呈現在擁有它的頁面上。 本頁的職責是提供這份坦率的地圖，而不是逐一證明每一點。

實務範例

最誠實的讀法，是把它當成一份簡短檢查清單。 只要其中任一項成立，NextPDF 對那項工作很可能就是錯的工具。 它仍可能在同一個系統中負責另一個部分。

Decision check — is NextPDF the wrong shape here?

[ ] You must render arbitrary modern web pages pixel-for-pixel,
    including JavaScript-driven layout.            → use a browser renderer
[ ] Your input is scanned/image-only PDFs you must
    turn into structured, searchable text.         → use an OCR pipeline
[ ] You need a binding PDF/A or PDF/UA pass/fail
    as the authoritative answer.                   → use an independent validator
[ ] The core workload is editing/redacting
    untrusted third-party PDFs.                    → use an editing/redaction tool
[ ] Your runtime is below the supported PHP floor
    and the backport path does not apply.          → use a different toolchain

None of the above ticked?
    → NextPDF is plausibly a good fit. Confirm against
      the design philosophy and the integration decision guide.

請留意這種不對稱性：勾選一個框只是把 NextPDF 排除在那項工作之外，而非排除在整個系統之外。 一條管線常常用一個工具做 OCR、用 NextPDF 產生最終的 PDF，再用第三個工具驗證符合性。 對的工具要用在對的階段。

常見誤解

常見的誤讀，是把「何時不該使用」這一頁當成承認弱點。 其實正好相反：有足夠自信畫出自身邊界的引擎，才是你能據以規劃的引擎。 風險從來不是別人告訴你的那條限制。 風險是那條因為沒人願意寫下來、結果你在生產環境才發現的限制。

第二種誤讀，是把這些當成對整個系統的永久裁決。 它們並不是。 「不適合算繪任意網頁的工具」並不等於「不適合你那個剛好包含一張圖表的發票開立服務的工具」。 它的意思是把算繪委派出去，把產生留在手上。 邊界是以工作為單位，而非以專案為單位。

限制與邊界

本頁本身也有邊界。 它陳述的是不適用的類別，而非一份具名替代方案的排名清單。 依照政策，點名與比較特定產品不在此處的範圍內。 正確的特定選擇取決於你的限制條件。 搭配的整合決策指南會在不做那種比較的前提下，把使用情境對應到生態系內的元件。

這也是截至本審閱日期的判斷。 能力邊界——尤其是版本邊界——會隨著引擎演進而移動。 相對地，符合性裁決的邊界是結構性的，預期不會移動。 無論產生能力變得多強，符合性都由獨立的驗證器決定。

最後，「editorial」是誠實標示的證據層級。 本頁提供推理，不做基準測試，也不引用程式碼。 當某項邊界確實是程式碼行為時，其證明會存在於擁有它的頁面上，並帶有該頁面的證據層級。

相關文件

• NextPDF 設計理念——為何此引擎會主動陳述邊界，而不是讓你自行摸索。
• HTML 管線——行程內的 HTML/CSS 引擎涵蓋與不涵蓋哪些範圍，以及何時該委派給瀏覽器算繪器。
• 整合決策指南——一份橫跨 NextPDF 生態系、由使用情境對應到元件的地圖，讓選擇權留在你手上，而非由我們暗示。

詞彙表

• Editorial（證據層級）——表示頁面陳述的是刻意且經過推理的判斷，經由論證而來，而非經由測量或引用程式碼。
• 必要而非充分——這是針對行程內檢查的刻意措辭；它是真實的訊號，但不是符合性裁決；具權威性的裁定屬於獨立的驗證器。
• 符合性與支援之別——符合性是已產出文件的一種二元屬性（它要嘛滿足某個具名設定檔，要嘛不滿足）；支援則是引擎的一種屬性（它把某項功能實作到所宣告的程度）。 驗證器衡量前者；引擎提供後者。
• PDF/A——用於長期封存 PDF 的 ISO 19005 系列設定檔。 產生它是一項版本能力；符合性裁決則永遠屬於獨立的驗證器。
• OCR——光學字元辨識，把頁面影像轉成文字。 這是一個與 PDF 產生不同的問題類別；此處在首次使用時展開說明。