直接回答
PDF 页面渲染图是文档外观的一种投影，不等于表单数据或交互行为的完整记录。如果 Android 流程把栅格页交给 OCR 或视觉模块，结果取决于所选 renderer 实际生成了什么。表单 widget、字段文本、文本标注、高亮、印章和页面内容可能由不同 PDF 结构和渲染开关控制。不能假设屏幕预览、打印输出、文本解析器和模型收到的位图包含相同信息。先定义需要的视图：用户看到的外观、排除标注的基础页面，还是另行解析的字段值。本文只核验只读渲染，不讨论填表、修改注释或提取权威业务字段。 Android PDF framework 在 Android V，也就是 API 35，增加了显著的 PDF 能力。更新后的 PdfRenderer 提供 getPdfFormType()，可以将文档分类为无表单、AcroForm、XFA foreground 或 full XFA。这只是处理分流线索，不是字段值 API，不保证支持每项 XFA 功能，也不证明脚本已执行。API 35 之前，框架 PdfRenderer 的基础能力主要是渲染页面。应记录设备 API 和准确的类；AndroidX PDF library 版本、系统扩展版本和平台 API 级别不能相互替代。 渲染控制也有不同版本边界。Platform RenderParams 的 text/highlight flags 标为 API 35；free-text/stamp flags 标为 version 36.1 和 S Extensions 18；表单内容模式另标为 version 36.1 和 S Extensions 19。官方说明 RENDER_FORM_CONTENT_DEFAULT 的默认行为不同：应用 target API 35+ 时 PdfRenderer 默认绘制表单，而 PdfRendererPreV 总是默认绘制。只有对应 API surface 可用时才能调用这些模式。不能把 version/extension 标签说成所有同名 Android 版本都有。如果用 AndroidX renderer，应固定库版本并使用该库自己的默认值。 表单类型、widget 值和控件的可见外观不能混为一谈。字段可能有逻辑值，但 appearance stream 可能过时、缺失，或被特定 viewer 渲染成不同外观。PDF/A 指南特别说明，符合 PDF/A 的文档应按 appearance dictionary 渲染字段，而不依赖字段数据本身；这个规则有 PDF/A 范围，不能泛化成任意 PDF 的普遍保证。因此位图最多支持“指定文件和设置下观察到此像素外观”的结论，不能证明原始字段值、JavaScript 或计算已成功执行，也不能证明用户意图。若下游任务需要准确金额或标识符，应使用独立 parser 合同、保留来源位置，并由用户复核重要字段。 用受控夹具分别隔离这些层。加入无表单页、字段为空和已填写的 AcroForm、可用的 XFA foreground/full XFA 样例、文本注释、高亮及不支持的注释类型。每份夹具记录源文件哈希、已知字段值、预期可见外观、表单类型，以及由具名工具生成的参考渲染图。在支持的设备上用明确注释标志渲染同一页面，再将像素或区域与参考结果比较。显示模式和打印模式要分开：打印视图可能有意不包含 viewer 专用标记，只匹配一种模式不能证明另一种模式也应一致。 空的 supported-annotation 列表不是“没有注释”的证据：PdfRenderer.Page.getPageAnnotations() 标为 version 36.1，只返回受支持类型，遇到其他 annotation 也可能为空。该方法文档未注明 S Extensions 18，不能把相邻 render flag 的扩展可用性套到它身上。渲染 flags 也不承诺显示所有对象。记录表单类型、flags、页索引、位图尺寸、target SDK、API/扩展版本和 unsupported 状态。保留源字节；位图不等于已编辑、展平或清理元数据的 PDF。 OCR 测试应建立在 PDF 外观测试之后。先确认 renderer 生成了预期可见区域，再针对该位图和独立参考检查 OCR/视觉结果。文本搜索可能从 parser 读取到字段字符串，即使控件在图像里看似空白；OCR 读取的是像素，无法可靠还原隐藏的表单状态。不要将二者合并成一个通过/失败标签。结论只能是：指定 renderer 在指定系统、夹具和 flags 下生成了经过核对的外观。它不证明 Cove 支持 PDF 表单、不保证所有 viewer 一致、不表明 XFA 或脚本已完整执行，也不证明 OCR 准确率有所提升。
OCR 没有读到 PDF 渲染图上的已填写字段
文档处理流程收到一份已填写的 PDF。文本搜索能找到字段标签，但 PdfRenderer 位图里的框看起来是空的。源文件可能包含 AcroForm 或 XFA，renderer 配置与目标系统 API 尚未记录。
决策
检查 PDF 表单分类和准确的 renderer API，再用已知夹具比对渲染像素。把逻辑字段解析与视觉 OCR 作为两条独立路径；不写回用户选择的文档。
预期结果
团队可以报告测试位图是否呈现预期控件外观，以及哪些格式/API 能力仍不支持，而不宣称已实现通用 PDF 表单提取。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- ANDROID-PDF-RENDER-STATE-2026-10：PdfRenderer 表单分类、注释标志及版本/扩展可用性应分别记录。
- OCR-DEDICATED-01：结构化文字识别与页面像素渲染属于不同输入路径。
- Android PdfRenderer 文档区分 API 35 与标注为 version 36.1/S Extension 的成员；PDF/A 表单外观规范是有限的格式合同，不代表所有 PDF 都一样。
任务质量需要有版本记录的语料和验收规则；流畅的单条样例不等于准确度结果。
实施流程
- 固定 PDF 与渲染实现. 记录源字节身份、Android API、扩展状态、target SDK、platform 或 AndroidX renderer 类、依赖版本、页索引以及显示/打印模式。保持原始文件不变。
- 分类表单和注释状态. API 35+ 可记录 getPdfFormType，但不能把它当字段提取结果。分别检查 getPageAnnotations 与各 render flag 的准确类和成员可用性，不从相邻 API 推断扩展回移。不支持的 XFA 或 annotation 类型要明确标出。
- 声明需要的视觉合同. 决定任务需要基础页面外观、表单控件，还是部分支持的 annotation。只使用准确 API 或固定 library 文档支持的 flags，并记录默认值而不是猜测。
- 比对参考夹具矩阵. 分别渲染无表单、空白/已填写 AcroForm、可用 XFA 和支持/不支持注释夹具。把明确标注的屏幕和打印输出与参考区域比较，保留原始 PDF。
- 渲染核验后再评价 OCR. 先确认预期 widget 像素存在，再对位图进行 OCR 或视觉评估。将 parser 文本、字段值、渲染外观和 OCR 分别记录。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 记录 PDF 字节、renderer 类/版本、平台 API、相关扩展、target SDK、页面、渲染模式及可用的注释/表单 flags。
- API 35、version 36.1 和 S Extension 成员严格区分；表单分类不是字段提取，且验证 PdfRenderer 与 PdfRendererPreV 的 target-SDK 表单渲染默认行为。
- 夹具分别检验基础页面、表单 widget 外观、支持的注释、显示/打印模式和 OCR，且不改写源字节。
- 不据此声称字段值准确、脚本已执行、任意 PDF 都兼容、Cove 已支持 PDF 或 OCR 准确率提升。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 页面栅格外观 | 在固定表单和注释设置下渲染页面 | 展示该 renderer 生成的像素；不暴露全部逻辑字段或交互行为。 |
| PDF 表单类型 | 可用时用 API 35 getPdfFormType 分类 | 返回 None、AcroForm、XFA foreground 或 full XFA；不提取字段，也不保证 XFA 支持。 |
| 支持的注释 flags | 只启用准确 API 或扩展记录支持的类型 | 特定 flags 不等于包含所有注释；较新的成员带有不同可用性标签。 |
| 文本 parser 或 OCR | 分别评估解析文本与渲染图 OCR | parser 可能读到位图未呈现的文本；OCR 能看像素，却不能读取隐藏表单状态。 |
需要避免的失败模式
- 把 API 35 的表单类型分类说成字段值读取或 XFA 全功能支持。
- 把标记为 version 36.1 或 S Extension 的方法宣传成所有新系统版本都有。
- 把渲染截图、文本解析、OCR、动态表单计算和 PDF 写回当成同一种结果。
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
- ML Kit text recognition
- Android privacy and security
- Android Developers — PDF viewer framework 与 API 级别
- Android API — PdfRenderer 表单类型
- Android API — RenderParams 注释与表单渲染 flags
- Android API — PdfRenderer.Page 注释与文本内容
- PDF Association — PDF/A 表单外观行为说明
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
getPdfFormType 会返回用户填写的字段值吗？
不会。Android 将其定义为 PDF 表单类型分类。应把它用于分流；准确字段值应使用独立且有文档支持的 parser，并由用户复核。
API 35 能保证每个注释都出现在位图里吗？
不能。text/highlight flags 标为 API 35，free-text/stamp flags 标为 version 36.1 和 S Extensions 18，而且都只覆盖文档支持的类型。应逐项测试并记录 API/extension。
RENDER_FORM_CONTENT_DEFAULT 在 PdfRenderer 和 PdfRendererPreV 中行为相同吗？
不相同。Android 文档说明 target API 35+ 的 PdfRenderer 默认绘制表单内容，而 PdfRendererPreV 始终默认绘制。表单内容模式本身标为 version 36.1 和 S Extensions 19。
空的 annotation 列表能证明 PDF 没有注释吗？
不能。PdfRenderer.Page.getPageAnnotations 标为 version 36.1，其文档未注明 S Extensions 18。它只返回受支持类型，遇到其他类型也可能为空；成员可用性必须与 render flags 分开检查。
这套流程可以填写或编辑用户选择的 PDF 吗？
不可以。本文核验 OCR/视觉处理前的只读页面外观，不编辑字段、更新注释、保存修改后的文档，也不表示 Cove 有 PDF 编辑器。