PDFium源码架构深度分析

I. PDFium 项目概览与架构蓝图

1.1 项目起源：从 Foxit 到 Google Chromium

PDFium 是一个高性能的开源 PDF 库，其技术血统源自两大行业巨头：Foxit（福昕软件）和 Google [1, 2]。该项目于 2014 年 6 月正式宣布，其初始代码库由 Foxit 提供 [1]。这一渊源至关重要，因为它决定了 PDFium 的核心架构 DNA。

Foxit 是一家领先的 PDF 解决方案提供商，其商业 PDF SDK 以跨平台能力和功能完整性著称 [3, 4]。PDFium 共享了驱动 Foxit 商业 SDK 的底层技术 [1, 3]，这意味着其初始架构（2014 年之前）是为一个功能全面、商业级的 SDK 设计的。

然而，自 2014 年 Google 接管并将其开源以来，PDFium 的演进方向被注入了“浏览器级”的基因。它被深度集成到 Chromium 项目中 [5]，并成为 Google Chrome 浏览器内置的 PDF 渲染引擎 [2]。这一转变使得项目的开发重点转向了极致的安全加固、高性能渲染以及与 Chromium 庞大构建体系的深度集成 [6, 7]。

这种“Foxit 商业”与“Google 开源”的双重起源，在架构上形成了一种微妙的“张力”。Foxit 的商业 SDK 提供了包括高级编辑、注释、安全和条形码在内的广泛功能 [4]。但对于 Google 而言，其核心目标是为 Chrome 浏览器维护一个最小化、最安全、最高效的渲染器。

对于需要评估此库的架构师而言，关键的结论是：不能假设 Foxit 商业 SDK [3] 的所有高级功能（特别是 PDF 编辑）在 PDFium 中都（免费）可用，即使它们“共享底层技术” [1]。PDFium 的核心是围绕 Google 的需求演进的：即“查看、搜索、打印和表单填写” [1]。

1.2 核心价值主张：为何 PDFium 是一个“浏览器级” PDF 引擎

PDFium 的核心价值主张不是其功能集，而是其安全性和健壮性。作为一个“浏览器级”引擎，它在 Chromium 项目中经受了实战检验，其设计目标是能够抵御来自互联网的、不可信的、甚至包含恶意负载的 PDF 文件的攻击，而不会损害宿主应用程序（如 Chrome 浏览器） [2]。

这种顶级的安全性是通过 Google 的大规模、持续的基础设施投入来实现的，特别是：

持续的模糊测试 (Fuzzing)： PDFium 是 Google ClusterFuzz [8] 等模糊测试框架的核心目标 [9]。它会持续不断地向 PDFium 注入自动生成的、损坏的输入数据，以发现潜在的安全漏洞 [10, 11, 12, 13]。
Chromium 集成： 作为 Chromium [5] 的 third_party 依赖 [9]，它享受着与浏览器内核同等级别的安全审查和加固标准。

对于技术决策者而言，这意味着 PDFium 是处理不可信来源 PDF（例如，SaaS 平台的用户上传、邮件服务器的附件处理、公共文档库）的黄金标准。

为这种顶级安全付出的“代价”是架构层面的：

沉重的构建系统： 它强制要求使用 Chromium 的 depot_tools 工具链 [6, 7]，集成复杂度远高于常规 C++ 库。
严格的 API 合约： 它对嵌入者（Embedder）提出了严苛的要求，例如强制的单线程模型 [14]，以牺牲“易用性”换取内部状态的一致性和可预测性。

架构上的权衡非常清晰：PDFium 是以“高集成复杂性”换取“世界级的安全性”。

1.3 架构蓝图：顶层目录与核心模块职责划分

PDFium 源码库的顶层目录 [5] 揭示了一个经过深思熟虑的、高度模块化的分层设计，这是大型 C++ 项目的典范。理解这些模块的职责是理解整个系统的关键。

表 1：顶层模块职责

模块 (Module)	核心职责 (Primary Responsibility)	关键组件/文件
`public/`	公共 API 层 (The Contract)：定义了嵌入者（Embedder）可以调用的纯 C API。这是唯一稳定的 ABI 接口 [14]。	`fpdfview.h`, `fpdf_text.h`, `fpdf_formfill.h`
`fpdfsdk/`	SDK 桥接层 (The Bridge)：封装内部 C++ 逻辑，将其转换为 `public/` 层的 C 句柄（Handle） [15]。	`fpdfview.cpp`, `fpdf_doc.cpp`, `formfiller/`
`core/`	核心 PDF 引擎 (The Engine)：PDF 规范的“字面” C++ 实现。平台无关，处理 PDF 解析、对象模型和渲染逻辑 [16, 17]。	`fpdfapi/parser/`, `fpdfapi/page/`, `fpdfapi/render/`
`fxge/`	图形引擎抽象层 (The Graphics Abstraction)：Foxit Graphics Engine。一个关键的抽象层，定义了图形绘制的接口（如 `CFX_RenderDevice`）。	`cfx_renderdevice.h`, `cfx_font.h`
`third_party/`	依赖项 (Dependencies)：所有外部依赖，如 `agg`, `freetype`, `libjpeg`, `v8`, `skia` 等 [18, 19, 20]。	`agg/`, `freetype/`, `v8/`
`fxjs/`	JavaScript 子系统 (The JS Subsystem)：V8 引擎的绑定层 [21]，用于实现 AcroForms 和 XFA 的 JavaScript 脚本 [22]。	`cfx_v8.h`, `cjs_app.cpp`
`xfa/`	XFA 子系统 (The XFA Subsystem)：一个并行的 XML 表单架构引擎 [23]。它是一个“引擎中的引擎”。	`xfa/`

理解 PDFium 的关键在于掌握其核心调用链：public -> fpdfsdk -> core。

当嵌入者调用一个公共 C API 时，例如 FPDF_LoadDocument() [14, 24]，该调用会按以下顺序穿透架构：

public/fpdfview.h [14]：C API 的定义，这是一个不透明的句柄 FPDF_DOCUMENT。
fpdfsdk/fpdfview.cpp [25]：C API 的实现。此文件将 C 调用（和 C 句柄）转换为 C++ 调用，创建并管理内部 C++ 对象。
core/fpdfapi/parser/cpdf_document.cpp [16]：核心 C++ PDF 文档对象模型（CPDF_Document）的实际实现，负责解析和管理页面树。

这种严格的分层（C API -> C++ 桥接 -> C++ 核心）确保了 API 的稳定性和内部实现的高度可维护性。

1.4 许可证分析：Apache 2.0 及其对企业集成的意义

PDFium 项目的 LICENSE 文件明确指定其采用 Apache License, Version 2.0 [26]。

这是一个对商业极其友好的“宽容型”（Permissive）许可证。与 GPL/AGPL [27, 28] 许可证不同，Apache 2.0 没有“强拷贝左”（Strong Copyleft）的限制。这意味着：

允许商业闭源使用： 企业可以在其闭源的商业产品中合法地使用、修改和分发 PDFium，而无需开源其产品的代码 [29]。
专利授权： Apache 2.0 包含一个明确的专利授权条款 [26]，这有助于降低企业在集成时面临的专利诉讼风险。

这是 Google 推动 PDFium（特别是作为 Chromium 的一部分 [5]）广泛采用的关键法律决策。

然而，对于架构师而言，真正的许可证风险不在 PDFium 本身，而在其庞大且复杂的依赖项 (DEPS) [27]。DEPS 文件 [5] 中列出的所有依赖项（如 V8, FreeType [20], lcms2, libjpeg-turbo, openjpeg 等）各自拥有不同的开源许可证。

[27] 资料中明确指出，“PDFium’s license as well as dependency licenses have to be shipped with binary distributions”。（PDFium 的许可证及其依赖项许可证必须随二进制分发版一起提供）。

这对任何大型企业都是一项严肃的法律合规工作。架构师必须对 DEPS 文件中的所有依赖项进行完整的许可证审计。这也解释了为什么市场上会存在如 pdfium.patagames.com [30, 31] 这样的商业封装：它们通过收费的方式，为您处理了构建、封装和法律合规的复杂性。

II. 依赖项、构建与集成体系结构

2.1 构建系统：深入分析 `depot_tools`, `gclient`, GN 与 Ninja

PDFium 的集成对架构师的第一个，也是最大的挑战，在于其构建系统。PDFium 无法通过常规的 cmake, make 或 Visual Studio 解决方案（sln）来构建 [7]。

它强制要求使用与 Chromium 完全相同的构建工具链 [5, 6, 22]。这套工具链包括：

depot_tools：这是 Google 的一套工具脚本，提供了 gclient 等核心工具 [7]。它是整个构建系统的入口。
gclient：一个元数据（meta）检出工具。它负责读取 DEPS 配置文件 [5]，并通过 gclient sync [7, 22] 命令，递归地检出 PDFium 源码及其所有（庞大的）依赖项。
GN (Generate Ninja)：一个元构建系统 [32]。开发者通过 gn gen <directory> [7, 22] 命令来配置构建。GN 会解析 .gn 和 .gni 文件，生成 Ninja 构建脚本 [32]。
Ninja：一个为速度而生的小型构建系统 [22]。gn 生成文件后，开发者运行 ninja -C <directory> [22, 33] 来实际执行（并行的）编译和链接。

对于一个不熟悉 Chromium 生态的团队来说，这套流程是一个巨大（但不可避免）的学习曲线和基础设施投入。任何试图“绕过”这个系统（例如，寻找预编译的 .dll [34]）的尝试，都将在未来升级和维护时导致灾难。

架构师的决定是：必须全盘接受 Chromium 构建体系。 您的 CI/CD 系统必须安装 depot_tools [7]，并学习 gclient [22]、GN [32] 和 Ninja [22] 的整套工作流。

2.2 关键构建配置：`pdf_enable_v8`, `pdf_enable_xfa`, `pdf_use_skia` 等标志的架构影响

GN [32] 提供了一个极其灵活的配置系统。通过 gn args <directory> [22] 设置的构建标志（flags），是架构师对 PDFium 进行“功能裁剪”和“架构决策”的主要控制点。

这些标志（定义在 pdfium.gni [18] 等文件中）允许在编译时裁切掉不需要的子系统，从而在功能、性能和安全攻击面之间做出权衡。

表 2：关键 GN 构建标志的架构影响

标志 (Flag)	默认值 (Default)	启用后的效果	架构师建议
`pdf_enable_v8`	`true` [22]	启用 V8 引擎 [18]。用于 AcroForms 和 XFA 的 JavaScript 支持 [22]。显著增加二进制大小、内存占用和安全攻击面。	强烈建议禁用 (`false`) [35]。除非业务明确需要 PDF 内的 JavaScript 脚本。
`pdf_enable_xfa`	`true` [22]	启用 XML Forms Architecture (XFA) 支持 [18, 36]。这是一个庞大的子系统 [23]，并强制要求启用 V8 [36]。	强烈建议禁用 (`false`) [35]。这是最大的“臃肿”来源。仅在必须处理遗留的政府或金融 XFA 表单时才启用。
`pdf_use_skia`	`false` [22]	使用 Skia 作为实验性图形后端 [18]，替代默认的 AGG [37]。	战略选择。如果您的宿主应用（如 Electron, CEF, Flutter）已经使用了 Skia，请设为 `true`。这可以实现资源合并，避免内存中同时存在 AGG 和 Skia。
`pdf_bundle_freetype`	`true` [18]	编译并静态链接 PDFium 捆绑的 FreeType 版本（位于 `third_party/freetype` [20]）。	必须保持 `true`。如 2.3 节所述，PDFium 依赖内部 FreeType API [20, 38]，无法链接系统 FreeType [39]。
`pdf_is_standalone`	`true` [22]	为独立（非嵌入式）构建设置，例如 `pdfium_test` [9, 22]。	用于构建测试程序时设为 `true` [35]。在作为库集成到宿主应用时，可能需要设为 `false`。

2.3 外部依赖 (`DEPS`) 分析

PDFium 不是一个单一的库，它是一个发行版（Distribution），通过 DEPS 文件 [5] 和 gclient [22] 捆绑了所有必需的依赖项。

关键依赖项包括：

V8：用于 JavaScript [18, 22]。
FreeType：字体渲染的基石 [20, 39]。
Skia：实验性图形后端 [18, 37]。
AGG (Anti-Grain Geometry)：默认图形后端 [19, 37]。
其他库：lcms2 (色彩管理), libjpeg-turbo / openjpeg (图像解码), icu (国际化，V8 依赖) [40, 41]。

在这些依赖中，FreeType 的集成方式是一个主要的架构风险点。third_party/freetype/README.pdfium [20] 文件明确指出，PDFium 不使用标准的 FreeType 公共 API。相反，它依赖于 FreeType 的内部头文件（例如 pstables.h） [20, 38]。

这意味着，任何试图通过设置 pdf_bundle_freetype = false [18] 来链接到“系统 FreeType” [39] 以节省空间的尝试，几乎注定会因为缺少这些内部头文件而构建失败 [38]。

架构师必须接受这一事实：必须使用 PDFium 捆绑的、经过轻微修改的 FreeType 版本。

2.4 集成成本与架构决策：将 PDFium 引入现有大型项目的挑战

综上所述，集成 PDFium 的成本主要在基础设施和架构决策，而非代码编写。

CI/CD 成本：必须重塑现有的构建流程，以完全适应 depot_tools 工具链 [7, 22]。
依赖项成本：必须接受 PDFium 的 DEPS [5] 文件所定义的特定、固定版本的依赖。如果您现有的项目也依赖 V8 或 FreeType，但版本不同，您将面临严峻的“依赖地狱”冲突 [39]。
封装成本：必须编写一个健壮的 C++ / Rust 包装器 [42, 43]，以安全地管理 C API [14] 的生命周期和严格的线程模型 [14]。
功能裁剪成本：必须投入架构时间，分析并主动（通过 GN [22]）禁用 V8 和 XFA [35]，以避免不必要的“功能臃肿”。

III. 公共 API 层 (`public/`)：嵌入者的合约

public/ 目录 [5, 44] 是 PDFium 的“门面”。它包含了所有面向嵌入者的头文件，这些头文件共同定义了 PDFium 的公共 API。这是嵌入者与 PDFium 内部实现之间的“铁律合约”。

3.1 API 设计哲学：纯 C、句柄（Handle）与不透明指针

PDFium 的公共 API [14] 遵循一个经典且健壮的 C 语言 SDK 设计模式：

纯 C 接口：所有公共 API 都是纯 C 函数 [14]。
不透明指针 (Opaque Pointers)：API 通过“句柄”（Handles）来操作所有对象。这些句柄被 typedef 为不透明的指针，例如 typedef struct fpdf_document_t__* FPDF_DOCUMENT; [14]。其他句柄包括 FPDF_PAGE、FPDF_BITMAP、FPDF_TEXTPAGE 等 [14, 45]。

这是一个深思熟虑的架构决策，带来了三大好处：

ABI 稳定性 (Application Binary Interface)：C++ 缺乏稳定的 ABI（由于名称修饰、虚表布局等）。纯 C API 确保了稳定的 ABI。这意味着 PDFium 的 C++ 内部实现可以随意重构（例如，切换 std::map 为 absl::flat_map），而不需要重新编译嵌入者的代码，只要 C API 签名不变。
语言互操作性 (Interoperability)：C API 是“通用语言”。这使得 PDFium 可以被任何能调用 C 的语言轻松封装，如 C# (Patagames [30, 46])、Go (go-pdfium [47, 48])、Rust (pdfium-render [42, 43])、Python (pypdfium2 [27]) 和 Dart [49]。
强制封装 (Encapsulation)：嵌入者无法（也不应该）直接访问内部的 C++ 对象（如 CPDF_Document [16]）。这强制执行了严格的封装，防止了实现细节的泄露，并使得 API 团队可以自由地改进内部实现，而不必担心破坏外部依赖 [50]。

3.2 `fpdfview.h` 详解：库、文档、页面的生命周期管理

fpdfview.h [14] 是最核心的头文件，它定义了库和文档的基本生命周期。

API 强制执行了一个严格、手动的资源生命周期管理模型 [51]：

库 (Library)：FPDF_InitLibraryWithConfig() [14, 24] 必须在任何其他调用之前被调用，以初始化全局资源。FPDF_DestroyLibrary() [14, 24] 必须在最后被调用，以释放这些资源。
文档 (Document)：FPDF_LoadDocument() [24]、FPDF_LoadMemDocument() [14, 52] 或 FPDF_LoadCustomDocument() [53] 用于加载 PDF 并返回一个 FPDF_DOCUMENT 句柄。操作完成后，必须调用 FPDF_CloseDocument() [24, 51] 来释放文档句柄和相关的所有资源。
页面 (Page)：FPDF_LoadPage() [14, 51] 用于加载特定页面并返回 FPDF_PAGE 句柄。操作完成后，必须调用 FPDF_ClosePage() [51] 来释放页面资源。

这是 C API 最大的危险。资源管理完全依赖于开发者的纪律。忘记调用 FPDF_ClosePage [54] 或 FPDF_CloseDocument 将导致严重的内存泄漏 [54, 55]。

对于架构师而言，这意味着任何 PDFium 集成必须做的第一件事就是构建 RAII (Resource Acquisition Is Initialization) 包装器。

在 C++ 中，这意味着使用 std::unique_ptr 配合自定义 Deleter（例如，std::unique_ptr<fpdf_document_t__, decltype(&FPDF_CloseDocument)>）。
在 Rust 中，这意味着为 FPDF_DOCUMENT 包装器实现 Drop trait [42]。
在 Go 中，这意味着使用 runtime.SetFinalizer。

绝不允许在生产代码中手动调用这些 Close 函数。

3.3 线程模型：非线程安全（Single-Threaded）的设计及其对嵌入者的要求

fpdfview.h 的头文件注释 [14] 中包含一个至关重要的架构警告：

“NOTE: None of the PDFium APIs are thread-safe.”

“Barring that, embedders are required to ensure (via a mutex or similar) that only a single PDFium call can be made at a time.”

这是一个有意的设计选择，而不是一个缺陷。使一个像 PDFium 这样复杂的 C++ 库（充满缓存、状态和复杂的对象图）线程安全，将带来巨大的性能开销（例如，到处都是细粒度锁）和复杂性。PDFium 选择将此责任完全推给嵌入者，以换取无锁的单线程性能。

这对并发应用程序的架构有重大影响：

“简单”模型（全局锁）：在所有 PDFium 调用周围放置一个全局互斥锁 (Global Mutex)。pdfium-render [56] 库就是这样做的。这保证了安全 [14]，但扼杀了所有并行性。在一个 32 核的服务器上，您的 PDFium 实例仍然一次只能处理一个请求，使其成为系统瓶颈。
“高性能”模型（工作池）：创建一个工作池 (Worker Pool)。池中的每个工作线程（或进程）都拥有其自己的、完全独立的 PDFium 实例（可能需要 FPDF_InitLibrary）。一个主线程将 PDF 渲染任务分派到队列中，工作线程（在它们自己的线程上）串行地处理这些任务。

go-pdfium 库 [48] 明确地实现了这种高性能模型。对于任何严肃的服务器端应用，架构师必须选择“高性能”模型。这意味着 PDFium 不是一个简单的“链接库”，而是需要围绕它构建一个服务架构（例如，一个微服务或一个线程池服务）。

3.4 错误处理机制：`FPDF_GetLastError()`

PDFium 采用了一种类似于 Win32 GetLastError() 或 C errno 的错误处理机制。

当一个函数（如 FPDF_LoadDocument [24]）失败时，它通常会返回一个哨兵值（如 NULL 或 FPDF_BOOL 的 false）。fpdfview.h [14] 的注释指引开发者：“If this function fails, you can use FPDF_GetLastError() to retrieve the reason why it failed.”

FPDF_GetLastError() 会返回一个线程局部存储（Thread-Local Storage）中的错误代码。这种机制简单但脆弱：

非线程安全：如果您违反了 3.3 中的单线程规则，FPDF_GetLastError() 返回的值将是不可预测的（竞态条件）。
必须立即调用：您必须在失败的 API 调用之后立即调用 FPDF_GetLastError()。任何成功的 PDFium API 调用都可能会清除这个错误代码。

架构师的责任：在 RAII 包装器中（见 3.2），在检查到 NULL 或 false 返回值时，必须立即调用 FPDF_GetLastError() 并将其转换为一个更健壮的错误类型（如 C++ 异常、std::error_code 或 Rust Result），然后再执行任何其他操作。

3.5 平台抽象层 (Platform Abstraction Layer)

PDFium 是一个被动的库。它不直接执行任何平台相关的操作，如文件 I/O 或系统字体查找。相反，它通过 C 回调结构（Callback Structs）要求嵌入者（Embedder）为其执行这些操作。

这是 PDFium 得以跨平台（从 Windows [57] 到 Android [5, 58] 再到 WebAssembly [59]）的核心架构模式。

I/O 抽象 (FPDF_FILEACCESS)：
FPDF_LoadDocument() [24] 接受一个文件路径，但这是最不灵活的方式。FPDF_LoadCustomDocument() [52, 53] 接受一个 FPDF_FILEACCESS [53] 结构体。这个结构体 [41, 60] 基本上只包含两个字段：文件大小和一个函数指针 m_GetBlock [61]。
嵌入者需要实现 m_GetBlock [61] 回调。PDFium 在解析时会调用它，说：“请给我从偏移量 X 开始的 Y 字节数据”。这使得嵌入者可以从任何地方（内存、网络、数据库）为 PDFium 提供数据流，而 PDFium 对此一无所知。fpdf_dataavail.h [62] 中定义的 FX_FILEAVAIL 接口进一步增强了这一点，允许检查数据是否可用，以支持线性化 PDF 的渐进式加载。
字体抽象 (FPDF_SYSFONTINFO)：
fpdf_sysfontinfo.h [63] 定义了 FPDF_SYSFONTINFO 接口。PDFium 不知道如何从 /usr/share/fonts 或 C:\Windows\Fonts 读取字体。当它遇到一个 PDF 中引用但未嵌入的字体时，它会通过这个回调接口询问嵌入者：“我需要 ‘Arial’，请给我它的数据流。”
或者，嵌入者也可以在 FPDF_InitLibraryWithConfig() [24, 64] 中提供一个 m_pUserFontPaths 路径列表。
如果嵌入者（例如，一个 Wasm 应用 [65] 或一个最小的 Docker 容器）未能提供此接口或字体路径，PDFium 将无法找到任何系统字体，导致文本显示为乱码或空白 [65]。

架构师的责任：您必须实现这些平台回调。 它们是集成的必要部分，而不是可选的。

IV. 核心内部机制：PDF 对象模型与内存管理

public/ 层之下是 fpdfsdk/（桥接层），fpdfsdk/ 之下是 core/（核心引擎）。core/ 目录是 PDFium 的心脏，它在 C++ 层面实现了 PDF 规范。

4.1 `core/fpdfapi/parser`：PDF 解析器与对象工厂

core/fpdfapi/parser [16, 17] 目录包含了 PDF 的核心解析逻辑。cpdf_parser.cpp [66] 包含了解析器本身，它负责：

读取原始的 PDF 字节流。
查找和解析 xref（交叉引用表）或 Cross-Reference Streams。
根据这些信息构建一个内存中的对象图。
cpdf_document.cpp [16] 则负责管理文档级结构，例如页面树（Page Tree, /Type /Pages）。

PDF 解析是一个高度复杂且充满安全风险的过程。这个模块是 PDFium 的主要攻击面之一，也是 ClusterFuzz [12] 的重点测试对象。此模块必须能够优雅地处理来自 Fuzzer 的各种损坏和恶意的输入。

4.2 `CPDF_Object` 继承体系：`CPDF_Dictionary`, `CPDF_Array`, `CPDF_Stream` 等

core/fpdfapi/parser/cpdf_object.h [67] 定义了 PDF 内存对象模型的基类 CPDF_Object。

PDFium 采用了经典的多态面向对象设计。CPDF_Object 是一个基类，它有多个子类，直接对应于 PDF 规范中的基本数据类型 [14, 45]：

CPDF_Dictionary [17] (对应 /Type /Dict)
CPDF_Array [16] (对应 [...])
CPDF_Stream [16] (对应 stream/endstream)
CPDF_Number [66] (对应数字)
CPDF_Name (对应 /Name)
CPDF_String (对应 (...) 或 <...> )
CPDF_Reference (对应 1 0 R)
CPDF_Null (对应 null)

cpdf_parser [66] 的工作就是将 PDF 字节流物化（Materialize）为这个强类型的 C++ 对象图。例如，CPDF_Dictionary [17] 内部使用 std::map 来存储键值对。

这种设计是其性能的关键：PDFium 是一个**“解析一次，多次访问”**的系统。一旦 PDF 被解析为这个对象图，后续的渲染、文本提取等操作都将访问这个内存中的强类型结构，而不需要重新解析原始字节流。

4.3 内存管理：侵入式引用计数与 `RetainPtr<T>` 智能指针

PDFium 不使用 C++11 的 std::shared_ptr。它实现了一套自定义的、侵入式（Intrusive）的引用计数系统。

侵入式设计：对象（如 CPDF_Object、CFX_GlyphCache [68]）会继承自一个 Retainable 基类（该基类在对象内部维护一个原子引用计数器），并实现 Retain() 和 Release() 方法。
RetainPtr<T>：core/fxcrt/retain_ptr.h [69] 中定义了 RetainPtr<T>。这是一个智能指针，其行为类似于 std::shared_ptr：它在构造/赋值时调用对象的 Retain()，在析构时调用 Release()。当引用计数降至零时，Release() 方法会 delete this。
广泛使用：RetainPtr<T> 在 PDFium 的 core C++ 代码中被广泛使用 [66, 70]。CONSTRUCT_VIA_MAKE_RETAIN [69, 71] 宏被用来强制使用 MakeRetain<T>() 工厂函数来创建对象，确保其在堆上分配并正确初始化。

为什么不使用 std::shared_ptr？

这是一个性能和内存的权衡。std::shared_ptr 需要一个单独的控制块（Control Block）来存储引用计数，这会（轻微地）增加内存开销（每次分配 shared_ptr 都需要额外分配控制块）和内存局部性（Indirection）开销。侵入式引用（计数器在对象内部）更快，内存布局更紧凑。这是高性能 C++ 库（如游戏引擎、浏览器内核）的常见模式。

架构风险：循环引用 (Circular References)。

这种系统的最大风险是循环引用。如果 CPDF_Dictionary A 持有一个指向 B 的 RetainPtr，而 B 同时持有一个指向 A 的 RetainPtr，它们的引用计数将永远不会降到零，从而导致内存泄漏。[17] 中 CPDF_Dictionary 的头文件也引入了 weak_ptr.h，这表明 PDFium 确实使用弱指针（Weak Pointers）来解决这个问题，但这依赖于开发人员的纪律。

4.4 PDF 对象生命周期与潜在的内存泄漏风险

PDFium 的内存模型因缓存和 C API 边界而变得复杂。

对象缓存：[54] 中报告了一个典型的内存泄漏问题：调用 FPDF_RenderPageBitmap 然后 FPDF_ClosePage 后，内存使用量持续增加，并不会在页面关闭时释放。内存只有在 FPDF_CloseDocument 时才被释放。这表明页面引用的资源（如字体 CPDF_Font 或图像）在文档级别（CPDF_Document）被缓存 [72]。FPDF_ClosePage 只是释放了页面对象本身，但并未清除文档级的缓存。
C API 边界泄漏：[55] 报告了在 FPDF_LoadCustomDocument 加载失败时，GetBlockCallback 回调仍可能被引用，导致 PdfCustomLoader 无法被垃圾回收，从而泄漏整个 PDF 文件的内存。
API 包装困难：[42] 中一位 Rust 开发者详细描述了包装 PDFium C API 的困难。C API（如 FPDF_LoadCustomDocument [60]）要求 FPDF_FILEACCESS [53] 中的数据缓冲区在 FPDF_DOCUMENT 的整个生命周期内都保持有效。这在 Rust 的安全借用检查器（Borrow Checker）下创建了一个“自引用结构”（PdfDocument 引用了它自己拥有的 bytes），这是极其困难的 [42]。

架构师结论：PDFium 的 C API虽然具有跨语言互操作性，但其生命周期管理规则是为 C/C++ 的“不安全”内存模型设计的。将其封装到 Rust 或 Swift 等具有严格生命周期管理的语言中时，必须特别注意 I/O 和内存的生命周期，这比在 C++ 或 Go [48] 中要复杂得多。

V. 渲染管线深度解析 (`fxge`)

fxge (Foxit Graphics Engine) 是 PDFium 渲染管线的核心。它是一个抽象层，将 core 引擎的抽象绘制命令转换为具体的像素。

5.1 `FPDF_RenderPageBitmap` 调用流

FPDF_RenderPageBitmap() [54] 是一个高层 API，用于将 PDF 页面渲染到内存位图（Bitmap）[73]。它是一个便捷封装。

真正的入口点是 FPDF_RenderPage() [57, 74]。此函数可以渲染到各种“设备”，例如 Windows 的设备上下文（DC），这允许直接渲染到打印机 [57] 或 EMF（增强型图元文件）[74]。

一个简化的渲染调用流如下：

Embedder (C API)：调用 FPDF_RenderPage(..., page,...) [74]。
fpdfsdk (Wrapper)：将 FPDF_PAGE 句柄转换为内部的 CPDF_Page [75] C++ 对象。创建一个具体的 CFX_RenderDevice [76]（例如，基于 GDI DC [74] 或 DIBitmap [73]）。
core (Engine)：创建一个 CPDF_RenderContext [77] 和一个 CPDF_RenderStatus [78]。
core (Engine)：遍历 CPDF_Page [75] 上的所有 CPDF_PageObject（页面对象，如路径、文本、图像）[77]。
core (Engine)：对于每个对象，调用 CFX_RenderDevice [76] 上的相应虚方法（例如 device->DrawPath()）。
fxge (Device)：CFX_RenderDevice 的具体实现（如 CFX_AggDevice 或 CFX_SkiaDevice [79]）接收这些抽象命令，并将它们转换为最终的像素。

5.2 渲染上下文：`CPDF_RenderContext` 的角色

cpdf_rendercontext.h [77] 定义了 CPDF_RenderContext。它是一个状态机。

它在构造时需要 CPDF_Document 和 CPDF_PageImageCache [77]，持有渲染一个页面所需的所有“上下文”信息，例如对文档对象（CPDF_Document）的引用、页面资源（字体、图像）以及对图像缓存（CPDF_PageImageCache）的访问。

CPDF_RenderContext 的存在是为了支持渐进式渲染（Progressive Rendering）。CPDF_ProgressiveRenderer [78]（在 public/fpdf_progressive.h 中暴露）会持有 CPDF_RenderContext [77]。Continue() [78] 方法可以被多次调用，它会使用 CPDF_RenderContext 来恢复上一次的渲染状态，并继续渲染接下来的 kStepLimit（例如 100 个）[78] 对象，然后返回 ToBeContinued 状态。

这允许嵌入者在渲染一个复杂的页面时（不会阻塞主线程）可以“让出”CPU，从而实现响应式 UI。

5.3 图形设备抽象：`CFX_RenderDevice` 接口

CFX_RenderDevice [76, 80] 是 fxge 中最关键的接口。它被 CPDF_RenderContext [77] 和 CPDF_ProgressiveRenderer [78] 持有和调用。

这是一个经典的“访问者模式”或“端口与适配器”架构。core 渲染引擎（“端口”）是完全不可知的。它只知道如何调用 CFX_RenderDevice 上的虚方法（例如 DrawPath, DrawImage, DrawText）。

具体的 CFX_RenderDevice（“适配器”）负责将这些抽象的“绘制”命令转换为实际的输出：

CFX_AggDevice [37] 会将其转换为 AGG 栅格化调用。
CFX_SkiaDevice [79] 会将其转换为 Skia 画布调用。
[74] 中 FPDF_RenderPage(dc,...) 使用的 CFX_WindowsDevice [80] 会将其转换为 Windows GDI 调用（例如 Rectangle()）。

这是 PDFium 中最强大的（尽管是内部的）扩展点。理论上，架构师可以实现自己的 CFX_RenderDevice，将 PDF 页面“渲染”到任何后端（例如，SVG 文本、OpenGL 调用、3D 纹理）。

5.4 实现对比：AGG vs. Skia

PDFium 内部支持两个主要的栅格化后端：

AGG (Anti-Grain Geometry)：这是默认的后端 [37]。它通过 pdf_use_skia = false [22] 启用，并依赖于 third_party/fx_agg [19]。AGG 是一个高质量的 2D 矢量图形栅格化库。这是 Foxit 时代 [1] 继承的技术遗产，久经考验且非常稳定 [28]。
Skia：这是一个实验性后端 [18]，通过 pdf_use_skia = true [22] 启用。CFX_SkiaDevice [79] 是其实现。Skia 是 Google 的 2D 图形库，是 Chrome、Android 和 Flutter 的基石。

这是一个关键的架构合并决策。

使用 AGG（默认）：这是最稳定、最久经考验的路径。对于纯 CPU 栅格化，性能可能非常高。
使用 Skia [22]：这是未来的方向。其最大的好处是资源合并。如果您的应用程序已经使用了 Skia（例如，您是 Electron、CEF 或 Flutter 应用），启用此标志 [18] 意味着您不需要同时交付和运行 AGG 和 Skia 这两个庞大的图形库。这显著减小了二进制大小和内存占用。尽管它被标记为“实验性” [18]，但它在 Chromium [37] 中使用，并受到 Fuzzer [13] 的严格测试，因此非常稳定。

VI. 关键子系统：字体引擎与 FreeType 集成

字体是 PDF 渲染的核心，也是最复杂的部分之一。PDFium 的字体引擎（fxge 的一部分）与 FreeType 库深度集成。

6.1 `fxge` 中的字体管理与替换逻辑

core/fxge/fx_font.h [81] 定义了字体的核心属性（如 FXFONT_BOLD, FXFONT_FF_ROMAN）。当 PDF 请求一个字体（例如，”Helvetica”）但该字体未嵌入在 PDF 文件中时，PDFium 的字体管理器必须执行字体替换。

这是一个双重责任架构：

PDFium 的责任：处理所有嵌入在 PDF 流中的字体，以及 14 种 PDF 标准字体（如 Helvetica, Times-Roman）。
嵌入者的责任：提供系统字体。如 3.5 节所述，PDFium 通过 FPDF_SYSFONTINFO [63] 回调接口或 m_pUserFontPaths [24, 64] 列表来请求系统字体。

如果嵌入者（例如，一个 WebAssembly 应用 [65] 或一个最小的 Docker 容器）未能履行其责任，PDFium 将无法找到系统字体，导致文本（如 [65] 中的土耳其语字符）无法正确显示。

6.2 `CFX_GlyphCache`：字形缓存机制

core/fxge/cfx_glyphcache.h [68] 定义了 CFX_GlyphCache 类。这是一个关键的性能优化层。

文本渲染很慢，因为它涉及两个步骤：

栅格化：使用 FreeType 将矢量字形（字符形状）转换为位图。
绘制：将该位图绘制到 CFX_RenderDevice 上。

步骤 1（栅格化）非常耗时。CFX_GlyphCache [68] 是一个*“记忆” (memoization)* 层。当渲染引擎请求一个字形时（通过 LoadGlyphBitmap() [68]），缓存会检查它是否（在特定字体和尺寸下）已被栅格化：

Cache Miss (缓存未命中)：缓存调用 FreeType（慢速路径），将生成的位图存储在 std::map [68] 中，然后返回它。
Cache Hit (缓存命中)：缓存直接从 map 中返回先前栅格化的位图（快速路径）。

对于 CJK（中日韩）等具有数万个字形的字体，此缓存的内存占用可能相当可观，这是架构师应注意的内存权衡。

6.3 FreeType 集成：PDFium 如何封装和调用 FreeType

如 2.3 节所述，PDFium 与 FreeType 的集成是高度耦合和脆弱的。

PDFium 默认捆绑 FreeType (pdf_bundle_freetype = true [18])。
FreeType 源码位于 third_party/freetype [20]。
PDFium 对 FreeType 有本地修改，包括依赖一个非公开的头文件 pstables.h [20, 38]。
尝试使用系统 FreeType [39] 会导致构建失败，因为它缺少 pstables.h [38]。

这是一个针对“使用系统库”的主要架构红灯。架构师必须放弃“链接到系统 FreeType 以减小二进制大小”的想法。必须使用 PDFium 捆绑的、经过修补的 FreeType 版本。

6.4 平台字体与嵌入字体的处理

架构师必须区分渲染和文本提取这两个完全不同的概念。

渲染 (Rendering)：只需要字形（Glyphs）。PDFium 从（1）嵌入字体，（2）系统字体（通过 [63] 回调），或（3）替换字体中获取字形并绘制 [81]。
文本提取 (Text Extraction)：需要Unicode 字符。公共 API fpdf_text.h [82] 提供了 FPDFText_LoadPage 来提取文本。这依赖于 PDF 内部的 ToUnicode 映射表 [83]。

PDF 内部可能只存储了“字符代码 1”，ToUnicode 映射表会告诉 PDFium“代码 1 = ‘A’”。如果此映射表丢失或损坏，FPDFText_LoadPage [82] 将返回无意义的字符（如 [83] 中的 “VFKDDO”），即使 PDF 渲染看起来完全正确。

当用户报告“文本无法复制” [83] 或“文本显示不正确” [65] 时，必须区分这是渲染问题（[65]，可能是字体可用性问题）还是文本提取问题（[83]，可能是 ToUnicode 映射问题）。

VII. 深入字体处理：渲染回退与编辑策略

在 PDFium 中，“字体处理”在渲染（查看）和编辑（创建）两个场景下的逻辑截然不同。架构师必须理解这两种模式下的回退（Fallback）策略。

7.1 字体类型：嵌入、子集与未嵌入

首先，PDF 中的字体可以分为三类：

完全嵌入 (Embedded)：整个字体文件（如 .ttf）包含在 PDF 中。这保证了在任何系统上都能完美渲染，但会使文件变大。
子集嵌入 (Subset)：仅嵌入 PDF 中实际使用到的字符（例如，只嵌入 “H”, “e”, “l”, “o” 的字形）。这在保证渲染的同时显著减小了文件大小。PDFium 在保存时通常会执行此操作。
未嵌入 (Non-Embedded)：PDF 仅引用一个字体名称，例如 “Helvetica” 或 “ArialMT”。它期望查看器（PDFium）在宿主操作系统上找到这个字体。

7.2 渲染回退 (Viewing Fallback)：字体替换

当 PDFium 渲染一个未嵌入字体的 PDF 时，会触发**字体替换（Substitution）**机制。这是最常见的回退场景。

CFX_FontMapper：此机制的核心是 core/fxge/cfx_fontmapper.cpp。当 CPDF_RenderContext 需要一个未嵌入的字体时，它会请求 CFX_FontMapper 去查找一个替代品。
查找逻辑 (FindSubstFont)：CFX_FontMapper::FindSubstFont 的逻辑大致如下：
- 清理名称：它会智能地清理字体名称。例如，对于子集字体，它会剥离随机前缀（如 YATXCX+Arial 会被识别为 Arial）。
- 映射标准字体：它会将 PDF 规范定义的 14 种标准字体（如 “Helvetica”, “Times-Roman”）映射到常见的系统字体（如 “Arial”, “Times New Roman”）。例如，”Symbol” 字体会被特殊处理，以强制回退到 PDFium 内置的 Symbol 字体。
- 询问嵌入者：如果字体非标准，PDFium 会通过 3.5 节中提到的平台抽象层询问嵌入者。这有两种方式：
  1. m_pUserFontPaths：在 FPDF_InitLibraryWithConfig [24, 64] 时传入一个字体目录列表。PDFium 会扫描这些目录。
  2. FPDF_SYSFONTINFO：实现这个回调接口 [63]，PDFium 会主动调用它来枚举或映射字体。
失败的后果：如果上述所有步骤都失败（例如，在 Wasm [65] 或最小 Docker 容器中，没有提供系统字体），CFX_FontMapper 将无法找到合适的替代品。这会导致 CJK（中日韩）等非拉丁字符显示为“豆腐块”（tofu, □）或空白，或者像中那样，Cyrillic 字符无法显示。

7.3 渲染回退 (Viewing Fallback)：字形回退

这是一个更复杂、更细粒度的回退，发生在字体已找到（无论是嵌入的还是替换的），但该字体不包含所有需要的字形时。

例如，一个 PDF 页面使用了一个（未嵌入的）韩语 Hangul 字体，PDFium 成功将其替换为系统上的韩语字体。但如果这段文本中混杂了拉丁字符（如 “Hangul text with Latin chars”），而这个韩语字体本身不包含拉丁字母，会发生什么？

内部回退列表：PDFium 在内部 CPDF_Font 类中维护一个 font_fallbacks_ 向量（列表）。
逐字检查：在渲染文本时，如果 CPDF_Font 发现其主字体（m_Font）不支持某个字符（例如，”L”），它会遍历 font_fallbacks_ 列表，尝试用列表中的字体来渲染该字符。
硬编码的后备：在历史上（如一个 2016 年的提交中），这个回退列表被硬编码为包含 “Arial”。这样做的目的是确保即使用户正在查看的（例如）韩语字体不包含拉丁字符，那些拉丁字符也能被 “Arial” 抓取并正确显示，而不是变成空白。
渲染优化：渲染器（CPDF_TextRenderer）足够智能，它不会为每个字符都切换字体。它会“批处理”使用相同字体（无论是主字体还是回退字体）的连续字符，以最小化对 CFX_RenderDevice 的绘制调用。

7.4 编辑场景 (Editing Scenario)：回退即责任

这是您问题的核心。当使用 public/fpdf_edit.h API 添加新文本时，回退逻辑完全不同：几乎没有自动的字形回退，责任完全在于嵌入者。

编辑的字体 API：要在 PDF 上创建新文本，嵌入者必须：
- 获取 FPDF_FONT 句柄：你不能只告诉 PDFium “用 Arial 字体”。你必须提供一个字体。
- FPDFText_LoadFont：这是关键 API。嵌入者必须从文件系统（或内存）加载一个 .ttf 或 .otf 文件的原始字节，并将这些字节传递给 FPDFText_LoadFont。PDFium 会（在文档内部）创建一个字体对象，并返回一个 FPDF_FONT 句柄。这实际上是将该字体嵌入到了 PDF 中（或至少是其子集，当保存时）。
- FPDFPageObj_CreateTextObj：然后，嵌入者使用这个 FPDF_FONT 句柄来创建文本对象。
“回退”在哪里？
- 回退在于嵌入者的应用逻辑，而不是 PDFium 内部。
- 假设一个 C# 嵌入者加载了 arial.ttf 并获得了 FPDF_FONT arialFont 句柄。如果用户试图输入 “你好” 并使用 arialFont 句柄去创建文本对象，PDFium 不会自动去系统里寻找 CJK 字体来回退。它只会尝试使用 arialFont 来渲染 “你好”，结果将是无意义的乱码（如中报告的 “ÿÿÿÿÿ”）。
- 正确的编辑架构：一个健壮的 PDF 编辑器（嵌入者）必须自己实现类似 CSS font-family 的回退栈。
  1. 应用在启动时，通过 FPDFText_LoadFont 加载多种字体，例如：arial_font = FPDFText_LoadFont("arial.ttf"...)、noto_cjk_font = FPDFText_LoadFont("NotoSansCJK.otf"...) 等。
  2. 当用户输入文本时，应用自己必须分析文本内容。
  3. 如果文本是 “Hello”，应用选择 arial_font 句柄调用 FPDFPageObj_CreateTextObj。
  4. 如果文本是 “你好”，应用必须智能地切换到 noto_cjk_font 句柄来调用 FPDFPageObj_CreateTextObj。
  5. 如果文本是 “Hello 你好”，应用必须创建两个独立的文本对象（FPDFPageObject），一个用于 “Hello”（使用 arial_font），另一个紧邻其后，用于 “你好”（使用 noto_cjk_font）。

总之，在渲染时，PDFium 拥有复杂的自动字体替换 和字形回退 机制。但在编辑时，PDFium 假设嵌入者是专业的，它只提供加载字体和使用字体的工具；而选择哪个字体的“回退”责任，则完全交给了嵌入者。

VIII. 关键子系统：JavaScript 引擎 (`fxjs`) 与 V8 绑定

PDFium 能够执行嵌入在 PDF 文档中的 JavaScript，主要用于 AcroForms（标准表单）和 XFA（动态表单）的交互逻辑。这是通过 fxjs 模块和 Google 的 V8 引擎实现的。

8.1 `fxjs` 模块职责：连接 PDF 运行时与 V8 虚拟机

fxjs 是一个顶层目录 [5, 21]，它是一个翻译层或绑定层。它是 PDFium 内部唯一同时理解 PDFium C++ 内部对象（例如，CPDF_Annot）和 V8 C++ API（例如，v8::Object）的模块。

该模块包含：

cfx_v8.cpp / cfx_v8.h：V8 引擎的通用绑定和帮助类 [21]。
cjs_app.cpp, cjs_annot.cpp：PDF 特定 JavaScript 对象（如 app, Annot）的 C++ 实现 [21]。

这是 PDFium 的核心安全边界之一。除了 PDF 解析器，fxjs 是第二大攻击面。此处的漏洞（例如，cfx_v8.cpp [21] 中的类型混淆或生命周期错误 [84]）可能导致 V8 沙箱逃逸。

架构师的黄金法则：如果您不需要 AcroForms [85] 或 XFA [36] 脚本，必须在构建时设置 pdf_enable_v8 = false [35, 64]。 这将极大地减小二进制大小、内存占用和安全攻击面。

8.2 `cfx_v8.h`：C++ 与 JavaScript 的绑定层

PDFium 实现了一个自定义的 C++ 到 V8 的绑定框架，而不是直接使用 V8 的（复杂的）C++ API。fxjs_v8.h [86, 87] 是一个内部帮助层，”makes it easier to define native objects in V8”。

它提供了 CFX_V8 [88] 等帮助类，用于管理 v8::Isolate、v8::Context 和 v8::ObjectTemplate [89] 的创建。

这是 V8 嵌入的经典模式。fxjs/ [21] 中的 C++ 代码会为 PDF JS 对象（如 “App”, “Annot”）创建 v8::ObjectTemplate，并将 C++ 回调函数（如 cjs_app.cpp）附加到 JS 函数名上。当 PDF 中的 JS 调用 app.alert() [90] 时，V8 将此调用路由回 cjs_app.cpp 中绑定的 C++ 函数。

8.3 V8 Isolate 与 Context 管理：`FPDF_InitLibraryWithConfig` 的角色

v8::Isolate 是一个重量级的对象，代表一个独立的 VM 实例、堆和垃圾收集器。高效地管理 Isolate 是 V8 集成的核心。

FPDF_InitLibraryWithConfig() [24, 64] API 通过 FPDF_LIBRARY_CONFIG 结构体 [91] 为架构师提供了一个关键的决策点。该结构体包含 m_pIsolate 和 m_pPlatform 字段 [24, 64]。

传入 NULL（简单方式）：如 simple_with_v8.cc [91] 示例所示，如果 config.m_pIsolate 为 NULL [92]，PDFium 将创建并拥有自己的 V8 Isolate。这很简单，但如果您的主应用程序也使用 V8（例如，您是 Node.js、Electron 或 CEF 应用），您的进程中现在将有两个（或更多）V8 实例，这是巨大的内存浪费和性能开销。
传入现有的 Isolate（合并方式）：这是 Chromium 的方式 [39]。浏览器管理一个主 Isolate，并将其“借”给 PDFium [24]。simple_with_v8.cc [91] 展示了嵌入者如何初始化 V8 并将 Isolate 和 Platform 传入 FPDF_InitLibraryWithConfig()。

架构师建议：如果您的宿主应用已使用 V8，您必须选择合并方式 [39]。 尽管这增加了集成复杂性（您需要管理 V8 的生命周期），但它可以避免“V8 in V8”的资源灾难。

8.4 AcroForms 脚本支持的实现

PDFium 中的 JavaScript 不是一个浏览器环境。它是一个沙盒化的、最小化的Acrobat JS API [90] 实现。此 API 是特定于 PDF 的，包含 app、doc、field [93] 等对象，并提供 FORM_DoDocumentJSAction [85] 等 API 来执行它们。

[90] 中的分析是关键：PDFium 支持 app.alert(1)（Acrobat JS API）但不支持 confirm(1)（浏览器 JS API）。这是一个安全特性，而不是一个 bug。它证明了沙箱是有效的，防止 PDF 中的 JS 访问浏览器级别的功能或执行任意的 Web 脚本。

架构师必须告知产品经理，PDFium 的“JS 支持”仅限于 PDF 表单逻辑 [85]，不能用于运行任意的 Web 脚本。

IX. 关键子系统：表单架构 (AcroForms 与 XFA)

PDFium 支持两种完全不同且互不兼容的表单技术。

9.1 AcroForms：标准 PDF 表单的实现

AcroForms 是 PDF 规范原生的、标准的交互式表单技术 [93]。

API：fpdf_formfill.h [44] 是其公共 API。
实现：fpdfsdk/formfiller/ [15] 是 SDK 层的实现。
对象模型：AcroForms 是一个“跨越整个文档的单一、全局交互式表单” [93]。它由 PdfField（字段，定义数据）和 PdfControl（控件，定义外观）组成 [93]。

AcroForms 具有双重依赖：

数据模型：字段、值、外观 [93] 是 core 和 fpdfsdk/formfiller [15] 的一部分。
脚本：字段的计算、验证和格式化（例如，日期或数字）[85] 依赖于 fxjs/V8。

架构师结论：要获得完整的 AcroForms 功能，您必须启用 V8 (pdf_enable_v8 = true [22])。如果禁用 V8 [35]，表单字段可能可见但无法交互，或者计算字段将无法更新。

9.2 XFA 架构 (`xfa/`)：一个并行的 XML 表单世界

xfa [5, 23, 94] 是一个独立的顶层目录。XFA (XML Forms Architecture) [23] 不是 PDF。它是一个 XML 数据包，被嵌入在一个 PDF “包装器”中。

渲染一个 XFA PDF 意味着 PDFium 完全绕过其 core PDF 渲染管线。

xfa/ [23] 目录是 PDFium 内部的“第二引擎”。它有自己的 XML 解析器、自己的布局引擎（需要实现 CSS 的一个子集）和自己的渲染逻辑。这是一个极其庞大和复杂的子系统。

9.3 XFA 对 V8 的强依赖及其性能影响

XFA 规范深度依赖 JavaScript 来实现其所有动态逻辑（例如，表单的动态增长、计算和 Web 服务调用）。

构建配置 pdf_enable_xfa “暗示了 JS 支持” [22]。
README 中明确指出“XFA 功能需要 JavaScript” [36]。

这是对架构师的终极配置警告。启用 pdf_enable_xfa = true [18, 22] 会带来：

整个 xfa/ [23] 模块（一个 XML 布局和渲染引擎）。
整个 fxjs [21] 模块（V8 绑定）。
整个 V8 虚拟机。

这将导致二进制大小、内存占用和安全攻击面的爆炸性增长。

*架构师建议：除非您的客户（例如，政府、银行、保险）用 XFA 表单（通常是动态的）明确要求您支持，否则必须通过 pdf_enable_xfa = false [35] 禁用此功能。*

X. 安全性与稳定性架构：Fuzzing 与加固

PDFium 的核心价值在于其“浏览器级”的安全性。这种安全性不是偶然的，而是其架构设计和 Google 开发流程的直接结果。

10.1 Chromium 的安全模型：沙箱（Sandbox）与 PDFium

一个常见的误解是 PDFium 是一个沙箱。事实并非如此。

PDFium 本身不是沙箱。它是一个 C++ 库。在 Chrome 中，PDFium 运行在一个独立的、受沙箱限制的进程中。

fpdfview.h [95] 中有一个 FPDF_SetSandBoxPolicy() API，它允许设置 FPDF_POLICY_MACHINETIME_ACCESS [95, 96] 等策略。这个 API 的作用是允许沙箱（即 Chrome 进程）通知 PDFium 库：“你正处于沙箱中，不要尝试访问机器时间（例如 time()）”。

这是嵌入者（您）的责任，而不是 PDFium 的功能。简单地链接 PDFium 库不会给您带来 Chrome 级别的安全性。要实现这一点，架构师必须设计一个进程沙箱架构，在单独的、低权限的进程中运行 PDFium，并使用 IPC（进程间通信）与其通信。FPDF_SetSandBoxPolicy [95] 是这个庞大架构工作的最后一步，而不是其本身。

10.2 ClusterFuzz：PDFium 得以健壮的核心

PDFium 稳定性的主要原因是 ClusterFuzz [8]。

ClusterFuzz [8] 是 Google 的可扩展、分布式 Fuzzing 基础设施，它用于 Fuzzing 所有 Google 产品 [8]，包括 Chromium [10] 和 PDFium [9]。

Fuzzing (模糊测试) [10] 是一种测试技术，它将自动生成的、无效的、意外的或随机的数据（“inputs” [10]）作为输入，喂给目标程序，直到其崩溃。

这不是一个一次性的测试；这是一个持续的过程。Google 的庞大基础设施 [8] 正在不断地、大规模地攻击 PDFium [10]。它能发现（如 [11, 12, 13] 所示）人类编写的单元测试永远无法捕获的、复杂的内存损坏漏洞。

这是采用 PDFium 的最大理由。您将免费“继承”Google 顶级的安全测试基础设施。

10.3 关键的 Fuzzers 目标（`pdfium_fuzzer`）

Fuzzing 是细粒度的。团队不仅 Fuzz FPDF_LoadDocument，还 Fuzz 堆栈深处的单个组件。

pdfium_fuzzer [12, 13] 是主 Fuzzer，用于测试 PDF 的解析和渲染。
libfuzzer_pdf_codec_png_fuzzer [11] 是一个专门针对 PNG 编解码器的 Fuzzer。

[11] 中的崩溃报告（”Crash Type: Heap-buffer-overflow READ 1”）显示 Fuzzer 在 CCodec_BmpModule::ReadHeader（BMP 图像的头解析器）中发现了一个堆缓冲区溢出。

这是一种“纵深防御”的测试理念。它表明不仅是 PDFium 的“主干” [12]（如 PDF 解析器），甚至连“毛细血管”（如 [11] 中的 PNG/BMP 解码器）都经过了安全加固。这为架构师提供了极高的信心，相信该库能够抵御恶意文件的攻击。

XI. 资深架构师总结与集成建议

11.1 PDFium 的核心优势（性能、安全性、完整性）

安全性与健壮性 (Security & Robustness)：这是第一优势。 得益于 ClusterFuzz [8, 10] 的持续加固，PDFium 能够抵御恶意的、不可信的输入，使其成为处理用户上传内容（UGC）的理想选择。
性能 (Performance)：专为高性能构建，具有 CFX_GlyphCache [68] 等内部缓存，侵入式引用计数 [69]，以及可切换的图形后端（AGG vs. Skia [18, 37]）。
许可证 (License)：Apache 2.0 [26] 对商业闭源极其友好 [29]。
完整性 (Completeness)：提供了对 PDF 规范（包括 AcroForms [93] 和 XFA [23]）的完整实现，用于“查看、搜索、打印和表单填写” [1]。

11.2 主要架构挑战（构建依赖、线程模型、C API 封装）

挑战是重大的，并且完全是架构层面的。

构建系统 (Build System)：这是最大的集成障碍。 PDFium 不是一个“即插即用”的库。它强制要求使用全套 Chromium depot_tools [6, 7, 22]。您的 CI/CD 必须集成 gclient, GN 和 Ninja。这是不可协商的。
线程模型 (Threading Model)：API 明确非线程安全 [14]。嵌入者必须在外部提供串行化（例如，全局互斥锁 [56]）。对于高并发服务器，这强制要求您构建一个工作池架构 [48]，从而增加了复杂性。
C API 封装 (C API Wrapper)：C API [14] 是一个高风险的边界。它强制要求手动、易错的资源管理（Close [51, 54]）。您的团队必须编写一个健壮的 RAII 包装器（例如，C++ unique_ptr [97] 或 Rust Drop [42]）来管理这一切。
功能臃肿 (Feature Bloat)：默认构建 [22] 包含了 V8 和 XFA [36]，它们非常庞大。架构师必须主动地、有意识地裁剪功能（pdf_enable_v8 = false [35]）以获得精简的构建。

11.3 平台抽象层 - 嵌入者责任

以下表格总结了 PDFium 不做什么，以及架构师必须实现什么。

表 3：公共 API - 嵌入者责任

领域 (Domain)	PDFium 的行为 (PDFium’s Behavior)	嵌入者的责任 (Embedder’s Responsibility)	相关 API
线程安全 (Threading)	非线程安全 [14]。	必须在所有 C API 调用外部加锁，或使用线程池确保单线程访问 [48, 56]。	`fpdfview.h` (所有 API)
文件 I/O (File I/O)	不执行文件 I/O。通过回调请求数据 [53]。	必须实现 `FPDF_FILEACCESS` 回调，以从磁盘/网络/内存中读取数据 [61]。	`FPDF_LoadCustomDocument` [53], `FPDF_FILEACCESS` [60]
系统字体 (System Fonts)	不扫描系统字体目录 [65]。	必须实现 `FPDF_SYSFONTINFO` 回调，或提供 `m_pUserFontPaths` [24]。	`FPDF_SYSFONTINFO` [63], `m_pUserFontPaths` [64]
内存管理 (Memory)	C API 暴露原始句柄；`Close` 函数必须被调用 [51]。	必须实现 RAII 包装器 (如 `unique_ptr` 或 `Drop`) [42] 来管理句柄的生命周期，防止泄漏 [54, 55]。	`FPDF_CloseDocument` [24], `FPDF_ClosePage` [51]
沙箱 (Sandboxing)	不是沙箱。它是一个可被沙箱化的库。	必须（对于高安全性应用）在单独的、低权限的进程中运行 PDFium，并使用 IPC 通信。	`FPDF_SetSandBoxPolicy` [95]

11.4 集成路线图建议

阶段 1：构建与配置 (Build & Config)。投入 1-2 名工程师，只为了在所有目标平台（Linux, Windows, Mac [7]）上成功编译 pdfium_test [22]。可以使用 pdfium-binaries [49] 进行原型设计，但不能用于生产。此阶段的产出是一个可以检出 DEPS [5] 并成功构建的 CI 管道。
阶段 2：功能裁剪 (Feature Pruning)。在编写包装器之前，决定您的功能集。构建一个“精简版”（pdf_enable_v8 = false, pdf_enable_xfa = false [35]）和一个“完整版” [22]。测量二者的二进制大小和内存占用，然后做出架构决策。
阶段 3：C++ 包装器 (C++ Wrapper)。构建您的内部 SDK。这个包装器将使用 RAII 模式（例如，带自定义 deleters 的 std::unique_ptr [97]）来管理 C API 的生命周期 [14, 51]，并实现线程模型（例如，一个单例服务，其所有方法都被互斥锁 [56] 保护）。
阶段 4：平台抽象 (Platform Abstractions)。实现阶段 3.5 中所需的平台回调。这必须包括一个字体策略（实现 FPDF_SYSFONTINFO [63] 或提供 m_pUserFontPaths [24]）和一个自定义 I/O 策略 (FPDF_FILEACCESS [53])。
阶段 5：应用集成 (App Integration)。将您的主应用程序链接到您的内部包装器，而不是直接链接到 PDFium C API。

11.5 风险评估：何时选择 PDFium，何时应避免

何时选择 (Choose PDFium if):
1. 您的首要任务是处理不可信文件的安全性和健壮性 [8, 10]。
2. 您需要一个高吞吐量的服务器端渲染或数据提取（FPDFText_LoadPage [82]）引擎。
3. 您需要跨平台（Win, Mac, Linux [9], Android [5]）的一致渲染。
4. 您的团队已有或愿意投资于 Chromium 构建生态 [6, 7]。
5. 您需要一个对商业友好的 Apache 2.0 许可证 [26]。
何时避免 (Avoid PDFium if):
1. 您需要一个轻量级的、“只需几 MB”的库，并且无法承担 depot_tools [7] 的构建开销。
2. 您的主要需求是创建或高级编辑 PDF。PDFium 是查看器优先的 [1]。
3. 您无法承担工程开销来构建 C API 包装器 [42] 和线程模型 [14]。
4. 您处于一个极端的资源受限环境（例如，某些 IoT 设备），V8/XFA 的开销 [22] 是不可接受的。在这种情况下，“精简版”构建 [35] 是您唯一的选择。

参考资料

Foxit® PDF technology chosen for Google® Open-Source, accessed November 6, 2025, https://www.foxit.com/company/press/1614.html
The interesting history (and fascinating future) of PDF software - Foxit, accessed November 6, 2025, https://www.foxit.com/blog/the-interesting-history-and-fascinating-future-of-pdf-software/
Foxit® extends PDF software development kit to Mobile devices, accessed November 6, 2025, https://www.foxit.com/company/press/1616.html
Foxit PDF SDK (PDFium), accessed November 6, 2025, http://cdn01.foxitsoftware.com/pub/foxit/manual/en_us/FoxitPDFium5_2_DeveloperGuide.pdf
chromium/pdfium: The PDF library used by the Chromium project - GitHub, accessed November 6, 2025, https://github.com/chromium/pdfium
README.md - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+show/HEAD/README.md
PDFium, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/da587fab57602e5e10c058e6e632df513fba0c93/README.md
google/clusterfuzz: Scalable fuzzing infrastructure. - GitHub, accessed November 6, 2025, https://github.com/google/clusterfuzz
Git at Google - PDFium, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/
Fuzz testing in Chromium, accessed November 6, 2025, https://chromium.googlesource.com/chromium/src/+/main/testing/libfuzzer/README.md
Security: PDFium: Out-Of-Bounds Read in GetDWord_LSBFirst [40084446] - Chromium, accessed November 6, 2025, https://issues.chromium.org/40084446
pdfium_fuzzer: Abrt in CPDF_StreamContentParser::AddForm [400244796] - Issue Tracker, accessed November 6, 2025, https://issuetracker.google.com/issues/400244796
pdfium_fuzzer: Unexpected-exit in SkAbort_FileLine [41486084] - Issue Tracker, accessed November 6, 2025, https://issuetracker.google.com/issues/41486084
public/fpdfview.h - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/main/public/fpdfview.h
fpdfsdk - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/master/fpdfsdk
core/fpdfapi/parser/cpdf_document.cpp - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/refs/heads/main/core/fpdfapi/parser/cpdf_document.cpp
core/fpdfapi/parser/cpdf_dictionary.h - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/refs/heads/main/core/fpdfapi/parser/cpdf_dictionary.h
pdfium.gni - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/refs/heads/main/pdfium.gni
Diff - a5bd1f122db00bf5316586a8ddf4fbacc44c7d80^1..a5bd1f122db00bf5316586a8ddf4fbacc44c7d80 - platform/external/pdfium - Git at Google - Android GoogleSource, accessed November 6, 2025, https://android.googlesource.com/platform/external/pdfium/+/a5bd1f122db00bf5316586a8ddf4fbacc44c7d80%5E1..a5bd1f122db00bf5316586a8ddf4fbacc44c7d80/
third_party/freetype/README.pdfium, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/refs/heads/main/third_party/freetype/README.pdfium
fxjs - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/refs/heads/chromium/5812/fxjs
PDFium, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/master/README.md
xfa - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/master/xfa
Getting Started with PDFium, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/HEAD/docs/getting-started.md
fpdfsdk/fpdfview.cpp - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/refs/heads/chromium/3237/fpdfsdk/fpdfview.cpp
LICENSE - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/main/LICENSE
pypdfium2 - PyPI, accessed November 6, 2025, https://pypi.org/project/pypdfium2/
PDF rendering engine performance and fidelity comparison - Hyland Connect, accessed November 6, 2025, https://connect.hyland.com/t5/alfresco-blog/pdf-rendering-engine-performance-and-fidelity-comparison/ba-p/125428
PDFium in a commercial closed-source software. - Google Groups, accessed November 6, 2025, https://groups.google.com/g/pdfium/c/BkbitJ58PRM
Simple pricing for everyone - Pdfium.Net SDK, accessed November 6, 2025, https://pdfium.patagames.com/Purchase/
One time pay, yearly fee and future upgrades - Pdfium.Net SDK - Patagames.com, accessed November 6, 2025, https://pdfium.patagames.com/help/html/Licensing_Renewal.htm
GN is a meta-build system that generates build files for Ninja. - gn Git repositories - Git at Google, accessed November 6, 2025, https://gn.googlesource.com/gn/
PDFium - Google Git, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/401d4f235114d7857c9c284a70cbb53a3e49bca1/README.md
How to Build PDFium.dll with Gn and Ninja? (Preferably in one pdfium.dll) - Stack Overflow, accessed November 6, 2025, https://stackoverflow.com/questions/75723098/how-to-build-pdfium-dll-with-gn-and-ninja-preferably-in-one-pdfium-dll
What are the correct options to compile PDFium for Android? - Stack Overflow, accessed November 6, 2025, https://stackoverflow.com/questions/56548558/what-are-the-correct-options-to-compile-pdfium-for-android
Git at Google - PDFium, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium.git
pdf/pdfium/pdfium_engine.h - chromium/src - Git at Google, accessed November 6, 2025, https://chromium.googlesource.com/chromium/src/+/lkgr/pdf/pdfium/pdfium_engine.h
pdfium uses private freetype API (pstables.h) [42271702] - Chromium - Monorail, accessed November 6, 2025, https://bugs.chromium.org/p/pdfium/issues/detail?id=733
Why does PDFium bundle Freetype instead of using the system library? - Google Groups, accessed November 6, 2025, https://groups.google.com/g/pdfium/c/ggQqfFU3Pcw
c++ - Creating a dll in pdfium - Stack Overflow, accessed November 6, 2025, https://stackoverflow.com/questions/30236148/creating-a-dll-in-pdfium
pypdfium2-team/pypdfium2: Python bindings to PDFium, reasonably cross-platform. - GitHub, accessed November 6, 2025, https://github.com/pypdfium2-team/pypdfium2
lifetime problems with self-referential struct · Issue #44 · ajrcarey/pdfium-render - GitHub, accessed November 6, 2025, https://github.com/ajrcarey/pdfium-render/issues/44
newinnovations/PDFium-rs: Modern Rust interface to PDFium, the PDF library from Google - GitHub, accessed November 6, 2025, https://github.com/newinnovations/pdfium-rs
public - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/master/public/
public/fpdfview.h - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/refs/heads/chromium/4016/public/fpdfview.h
Pdfium.Net SDK: The C# PDF Library, accessed November 6, 2025, https://pdfium.patagames.com/
pdfium package - github.com/pure-project/go-pdfium - Go Packages, accessed November 6, 2025, https://pkg.go.dev/github.com/pure-project/go-pdfium
klippa-app/go-pdfium: Easy to use PDF library using Go and PDFium - GitHub, accessed November 6, 2025, https://github.com/klippa-app/go-pdfium
bblanchon/pdfium-binaries: Binary distribution of PDFium - GitHub, accessed November 6, 2025, https://github.com/bblanchon/pdfium-binaries
Public pdfium API to assert contents of PDF files? - Google Groups, accessed November 6, 2025, https://groups.google.com/g/pdfium/c/LvYRAUprnE8/m/IXuOj6FEFwAJ
Get PDF images in an array using PDFIUM to edit them - Stack Overflow, accessed November 6, 2025, https://stackoverflow.com/questions/72224050/get-pdf-images-in-an-array-using-pdfium-to-edit-them
pdfium package - github.com/klippa-app/go-pdfium - Go Packages, accessed November 6, 2025, https://pkg.go.dev/github.com/klippa-app/go-pdfium
Pdfium.FPDF_LoadCustomDocument Method, accessed November 6, 2025, https://pdfium.patagames.com/help/html/M_Patagames_Pdf_Pdfium_FPDF_LoadCustomDocument.htm
Issue 669 in pdfium: Memory leak when rendering pages. - Google Groups, accessed November 6, 2025, https://groups.google.com/g/pdfium-bugs/c/KO4Id_s4w-c/m/wqE9u_EuDQAJ
Memory Leak in PDFDocument.Load when Pdfium.FPDF_LoadCustomDocument returns, accessed November 6, 2025, https://forum.patagames.com/posts/t805-Memory-Leak-in-PDFDocument-Load-when-Pdfium-FPDF-LoadCustomDocument-returns-an-IntPtr-Zero
ajrcarey/pdfium-render: A high-level idiomatic Rust wrapper around Pdfium, the C++ PDF library used by the Google Chromium project. - GitHub, accessed November 6, 2025, https://github.com/ajrcarey/pdfium-render
Pdfium.FPDF_RenderPage Method, accessed November 6, 2025, https://pdfium.patagames.com/help/html/M_Patagames_Pdf_Pdfium_FPDF_RenderPage.htm
Does anyone have an experience with PDFium to render/view PDFs? : r/androiddev - Reddit, accessed November 6, 2025, https://www.reddit.com/r/androiddev/comments/40v5w0/does_anyone_have_an_experience_with_pdfium_to/
Jaewoook/pdfium.js: A PDFium wrapper library for browser-side JavaScript - GitHub, accessed November 6, 2025, https://github.com/Jaewoook/pdfium.js/
pypdfium2 · PyPI, accessed November 6, 2025, https://pypi.org/project/pypdfium2/3.5.0/
Cannot load JPG image Pdfium - Stack Overflow, accessed November 6, 2025, https://stackoverflow.com/questions/71024937/cannot-load-jpg-image-pdfium
public/fpdf_dataavail.h - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/main/public/fpdf_dataavail.h
public/fpdf_sysfontinfo.h - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/refs/heads/main/public/fpdf_sysfontinfo.h
docs/getting-started.md - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+show/HEAD/docs/getting-started.md
How to load the custom font in pdfium.wasm · Issue #163 - GitHub, accessed November 6, 2025, https://github.com/bblanchon/pdfium-binaries/issues/163
core/fpdfapi/parser/cpdf_parser.cpp - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/master/core/fpdfapi/parser/cpdf_parser.cpp
core/fpdfapi/parser/cpdf_object.cpp - platform/external/pdfium - Git at, accessed November 6, 2025, https://android.googlesource.com/platform/external/pdfium/+/1ed3da3f0/core/fpdfapi/parser/cpdf_object.cpp
core/fxge/cfx_glyphcache.h - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/refs/heads/chromium/6803/core/fxge/cfx_glyphcache.h
core/fxcrt/retain_ptr.h - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/HEAD/core/fxcrt/retain_ptr.h
Security: Pdfium: integer overflows in pattern shading [40089917, accessed November 6, 2025, https://issues.chromium.org/issues/40089917
Diff - bc260fd7e338f266d4e41e979c57c100ae9661b6^1..bc260fd7e338f266d4e41e979c57c100ae9661b6 - platform/external/pdfium - Git at Google - Android GoogleSource, accessed November 6, 2025, https://android.googlesource.com/platform/external/pdfium/+/bc260fd7e338f266d4e41e979c57c100ae9661b6%5E1..bc260fd7e338f266d4e41e979c57c100ae9661b6/
pdfium - Confused about ownership of font objects - Google Groups, accessed November 6, 2025, https://groups.google.com/g/pdfium/c/Ur0XHQeMnAo
Render PDF Page to Bitmap using Pdfium - Stack Overflow, accessed November 6, 2025, https://stackoverflow.com/questions/28448474/render-pdf-page-to-bitmap-using-pdfium
How to render the PDF page as EMF or meta file in PDFium - Stack Overflow, accessed November 6, 2025, https://stackoverflow.com/questions/49153715/how-to-render-the-pdf-page-as-emf-or-meta-file-in-pdfium
core/fpdfapi/page/cpdf_page.h - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/refs/heads/main/core/fpdfapi/page/cpdf_page.h
accessed January 1, 1970, https://pdfium.googlesource.com/pdfium/+/main/core/fxge/cfx_renderdevice.h
core/fpdfapi/render/cpdf_rendercontext.cpp - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/HEAD/core/fpdfapi/render/cpdf_rendercontext.cpp
core/fpdfapi/render/cpdf_progressiverenderer.h - platform/external/pdfium - Git at Google, accessed November 6, 2025, https://android.googlesource.com/platform/external/pdfium/+/1ed3da3f0/core/fpdfapi/render/cpdf_progressiverenderer.h
fpdfsdk/src/fpdfview.cpp - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/3522876d5291922ddc62bf1b70d02743b0850673/fpdfsdk/src/fpdfview.cpp
Diff - e749a90be03a6f39751ce0825d9f9a3969aabbed^2..e749a90be03a6f39751ce0825d9f9a3969aabbed - platform/external/pdfium - Git at Google - Android GoogleSource, accessed November 6, 2025, https://android.googlesource.com/platform/external/pdfium/+/e749a90be03a6f39751ce0825d9f9a3969aabbed%5E2..e749a90be03a6f39751ce0825d9f9a3969aabbed/
core/fxge/fx_font.h - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/163817/core/fxge/fx_font.h
public/fpdf_text.h - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/main/public/fpdf_text.h
FPDFTextObj_GetText returns glyph ids instead of text - Google Groups, accessed November 6, 2025, https://groups.google.com/g/pdfium/c/tDoOI6srATQ
Security: PDFium Use-After-Free in v8::internal::ArrayBufferExtension::Mark [40057625], accessed November 6, 2025, https://issues.chromium.org/40057625
Pdfium Methods, accessed November 6, 2025, https://pdfium.patagames.com/help/html/Methods_T_Patagames_Pdf_Pdfium.htm
fpdfsdk/include/jsapi/fxjs_v8.h - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/chromium/2694/fpdfsdk/include/jsapi/fxjs_v8.h
fxjs/cfxjs_engine.h - pdfium.git - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium.git/+/refs/heads/chromium/7404/fxjs/cfxjs_engine.h
fxjs/xfa/cfxjse_engine.cpp - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/refs/heads/chromium/4642/fxjs/xfa/cfxjse_engine.cpp
Wrapping a C++ Object to a v8 Object in a Node Addon - Stack Overflow, accessed November 6, 2025, https://stackoverflow.com/questions/16329491/wrapping-a-c-object-to-a-v8-object-in-a-node-addon
JavaScript-based PDF Viewers, Cross Site Scripting, and PDF files | Blog un po’ nerd, accessed November 6, 2025, https://gubello.me/blog/pdf-viewers-xss-and-pdf-files/
samples/simple_with_v8.cc - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/master/samples/simple_with_v8.cc
Getting Started with PDFium, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium.git/+/abefb79577b32d291d14d7e/docs/getting-started.md
Get access acroforms - Pdfium.Net SDK, accessed November 6, 2025, https://pdfium.patagames.com/help/html/WorkingSDK_AcroForms.htm
xfa - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/xfa
public/fpdfview.h - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/e8c1d4144/public/fpdfview.h
public/fpdfview.h - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/old_master_before_xfa/public/fpdfview.h
fpdfsdk/fpdf_editpage.cpp - pdfium - Git at Google, accessed November 6, 2025, https://pdfium.googlesource.com/pdfium/+/refs/heads/main/fpdfsdk/fpdf_editpage.cpp