何时不应使用 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、Web 字体、由 JavaScript 驱动的布局。这是浏览器负责的问题。
• 你需要对扫描件或纯图像 PDF 进行 OCR 或重建，将其转为结构化文本。这属于 OCR/文档理解问题，而非生成问题。
• 你需要一个合规裁定（PDF/A、PDF/UA、PAdES）作为权威答案。NextPDF 生成的是以合规为目标的结构；至于是否真的合规，由独立的验证器来裁定。
• 你的核心工作负载是对第三方 PDF 进行大量交互式编辑或涂黑（redaction），而非生成或检视它们。
• 你的运行时低于所支持的 PHP 下限，且无法使用回溯移植（backport）路径。

在每一种情况下，问题都在工具类别，而不在质量：正确的答案是另一类工具。

NextPDF 如何对待这件事

NextPDF 是一个 PHP 引擎，用于生成 PDF 2.0 文档，并检视这些文档以获取结构性事实。它的设计——意图显式、输入快速失败（fail-fast）、进程内且确定性——正是为这项工作而调优的。这些诚实的边界，正标出了问题本质上属于另一种形态的地方。

下表把每一种不适用的情形，对应到它为何属于错误的形态，以及哪类工具才适合。不点名任何具体产品；重点在于类别。

如果你的问题是……	为何 NextPDF 是错误的形态	哪类工具才适合
对任意现代网页进行像素级忠实渲染	进程内的 HTML/CSS 引擎面向的是一个有明确定义、有文档说明的子集，以获得可预测、确定性的输出——而非整个不断演进、带脚本的 Web 平台	一个真正的浏览器引擎（无头浏览器渲染器），通过生态系统的浏览器桥接来驱动
将扫描件或纯图像 PDF 转为结构化文本	NextPDF 不执行 OCR 或文档理解；它进行生成与结构性检视，不会从像素中推断语义	一条专门的 OCR/文档理解流水线；如果之后你需要生成一份 PDF，再把它的输出交给 NextPDF
一个权威的合规裁定	进程内检查是必要而非充分的——它们在设计上报告的是结构性事实，而非 pass/fail 的裁决	以独立验证器（例如某个公认的 PDF/A 或无障碍检查工具）作为关卡
以对任意 PDF 进行大量交互式编辑/涂黑作为核心工作	该引擎是为生成与结构性检视而优化的，而不是针对不可信第三方文件的通用往返（round-trip）编辑器	一类为 editing/redaction 工作流而打造的工具；把 produce/inspect 的部分交给 NextPDF
一个低于所支持 PHP 下限的运行时	该引擎刻意构建在现代 PHP 语言特性之上	在适用时采用有文档说明的回溯移植路径；否则改用另一套工具链

反复出现的主题，是这个引擎对自身能力的诚实。它的进程内合规检查在自己的输出中就是这样表述的：它们是必要而非充分的——一个干净的结果「并不确立 ISO 合规性」，而裁定「属于独立的验证器」。它的快速 PDF 检视器也以同样方式定位自己：它是「一种快速的结构性分诊，而非验证器……它不验证签名、不解密内容，也不断言合规性。应把结果当作路由输入，而非信任裁定。」该引擎拒绝对自己夸大其词。这正是为什么一个拒绝过度营销它的页面，与该引擎是一致的。

有些边界并非固定界线，而是版本（edition）边界。例如，归档（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

把局限放在推销说辞之前，是一个有意为之、且有标准依据的选择。简明语言（plain-language）指南明确指出，大多数读者所需的信息应排在只有部分人需要的信息之前，并且警示应当放在操作说明之前，而非之后 （ 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（编辑性，证据等级） —— 一个陈述有意作出的、经过推理的判断的页面，靠论证而非测量或引用代码来支撑。
• 必要而非充分 —— 一种刻意的措辞，用于描述这样一种进程内检查：它是一个真实的信号，但并非合规裁定；权威的裁决属于独立的验证器。
• 合规 vs 支持 —— 合规是已生成文档的一个二元属性（它要么满足某个具名的配置文件，要么不满足）；支持则是引擎的一个属性（它以所声明的程度实现某项特性）。验证器衡量的是前者；引擎提供的是后者。
• PDF/A —— 用于长期归档 PDF 的 ISO 19005 配置文件系列。生成它是一项版本能力；而合规裁定始终属于独立的验证器。
• OCR —— 光学字符识别（Optical Character Recognition），将页面图像转为文本。这是一个与 PDF 生成相区别的问题类别；此处在首次使用时给出全称。