能力边界

以下是目前已知且明确声明的限制。文档站不隐藏它们——评估技术选型时，这些比优点更重要。

图像编码

编码	状态	说明
PNG / JPEG / BMP / TIFF	✅ 完整支持	渲染与提取（dataURL）
CCITT G3 / G4（传真）	✅ 支持	G3（K=0/1）自研解码；含国标样例 ccitt_gb_logo.g4 回归
JBIG2	✅ 基本完整	解码已实现：MMR/MQ、symbol dictionary 与 text region（Huffman+算术）、refinement 全路径（v0.10.0 起：TPGRON 典型预测、SDREFAGG 聚合重构、精化实例、AND/XNOR 组合算子）、halftone 区域、二维码样例回归。仍降级的罕见组合：SDHUFF×SDREFAGG（生态零实现，pdf.js 同样拒绝）、halftone 的 HSKIP/灰度 MMR/非 OR 灰度拼贴——不支持时渲染为占位框
JPEG2000 (JPX)	✅ 支持	转换端 v0.6.0 起真解码（含空 tile 恶意流围堵）；OFD 渲染端 v0.10.0 起经 openjpeg 真解码（ofd-jpx 模块，魔数嗅探前置，解码失败回落占位框）；SES 印章位图同步支持

渲染近似

• PDF 中的 shading（渐变网格）与混合模式为近似还原，复杂透明叠加可能有视觉差异；ExtGState 亮度型软掩码（/SMask 无 /Alpha）与非隔离混合组按无掩码基线渲染
• 视频对象静态渲染呈现封面图（PosterID，v0.11.0 起；数科同观感），不播放画面——播放由阅读器经 pageVideos + mediaBytes 自建播放器实现（vue-demo 已内置）
• Clips/@TransFlag 属性解析保真但不影响渲染：语料实证（60 文件 / 6788 处几乎全为 false，ofdrw 写出件缺省如此）且 ofdrw 读取端不消费该属性，渲染变换链对 true/false 一致（94 语料对拍锁定口径）

PDF → OFD 转换

• 无 ToUnicode 映射的 PDF 文本：先经多层反查恢复（嵌入字体 GID→Unicode、BaseFont UTF-16、GBK/GB2312 双字节解码、CID 桩字体按 BaseFont 名反查系统字体），判定不了的字形按保真轮廓渲染但不可检索（宁缺勿错，不错配）
• JPX/JBIG2 图像按上表规则处理并记入 report.warnings

OFD/A 归档

• 多文档（DocBody > 1）仅处理首个文档，检测会提示 single-doc 不合规
• 浏览器端字体嵌入依赖用户授权读取系统字体（Chromium queryLocalFonts），未授权时仅报告不嵌入

平台

• 原生构建目标：Windows x64（MSVC / xwin）
• WASM 目标：wasm32-unknown-unknown（浏览器与 Node ≥ 18）
• Linux/macOS 原生构建未做持续验证（代码无平台依赖，理论上可编）

安全声明

• 验签结论依赖调用方提供的信任锚：不配置锚时只校验签名值与摘要，链结论为「未配置信任锚」——这是有意的诚实设计，避免无锚情况下给出误导性的「可信」结论
• 加密使用国密算法（libsm 实现），未经过第三方密码审计