简介面向 C 开发者的 PDFlib 9.1.2 干净去水印版资源用于解决在项目中读写、生成和编辑 PDF 时官方水印干扰输出的问题。与仅剔除字符水印的版本不同该包彻底清除了页面上的 www.pdflib.com 文字及其背后的水印文本框输出背景纯净可放心用于正式文档或二次封装。资源包共 461 个文件压缩后约 53.76MB包含 95 个 PDF 示例文档、63 个 VCXPROJ 工程文件、33 个 C/C 源文件以及 TTF、AFM、OTF 等字体文件和头文件、静态库、动态库等运行依赖同时保留 EXE 可执行文件、PDB 调试符号、SDF 智能感知数据库并附有 JPG/TIF 示例图片与 TXT 说明便于直接运行验证和对照输出效果。作者基于 VS2019 整理了带详细注解的示例工程按说明用记事本修改 sln 版本号即可降级至 VS2010适合需要快速集成 PDF 功能或研究 PDFlib API 调用细节的初中级开发者。目前已有 134 人浏览学习可作为集成 PDF 功能、研究 API 调用流程及排查环境问题的实用参考。1. PDFlib 9.1.2 去水印别只删字符串文本框才是残留重灾区拿到一个 PDFlib 9.1.2 的资源包很多人第一时间会去生成的 PDF 里搜 www.pdflib.com搜到就替换掉。但实际产物里仍然会有一块浅色矩形这就是评估版绘制的水印文本框。只改动文本字符内容流里的矩形绘制指令还在输出照样不干净。这个包解决的问题就是两步都清掉既没有水印字符串也没有水印框。下面从 VS2019 工程配置开始逐步拆解引用方式、字体映射和最后的验证方法如果你需要降级到 VS2010也会说明 sln 版本号怎么改。适合用 C 集成 PDF 生成能力的开发者和维护旧版项目的工程师。2. VS2019/VS2010 下 PDFlib 9.1.2 的编译链接与降级配置在 C 项目里引用 PDFlib通常不是把整个 examples 工程直接搬过来而是单独建一个控制台工程把库路径配好再一个文件一个文件地加代码。这一章先解决环境问题。2.1 库目录里到底哪些文件会被用到先看资源包里与编译相关的核心文件。Windows 下 PDFlib 的二进制分布通常是这样的结构pdflib/9.1.2/ ├── include/pdflib.hpp ├── include/pdflib.h ├── lib/pdflib.lib ├── bin/pdflib.dll ├── resource/font/Adobe-Japan1-UCS2 ├── resource/font/LuciduxSans-Oblique.afm ├── resource/font/TIR_____.AFM └── examples/pdflib.hpp是 C 封装头文件pdflib.h是 C 接口链接时用到pdflib.lib运行期需要pdflib.dll。资源文件里的 AFM 和 Adobe-Japan1-UCS2 则用于字体度量与 CID 映射第 4 章会专门讲。多数编译错误的根源不是代码逻辑而是 DLL 和 LIB 路径没配对LIB 在链接器路径里DLL 在 PATH 里两个位置不一致就会出现“应用程序无法启动”或“无法解析的外部符号”。2.2 新建 VS2019 C 工程并配置库引用我在实际项目中一般建一个空的控制台应用然后手动配置。打开“项目属性”的“VC 目录”“包含目录”添加include文件夹。“库目录”添加lib文件夹。在“链接器 → 输入 → 附加依赖项”里写入pdflib.lib。把pdflib.dll复制到输出目录或直接把bin加入系统 PATH。然后粘贴一个最小生成例子测试链接#include cstdio #include pdflib.hpp int main() { PDFlib p; // 初始化并检查错误码begin_document 返回 -1 表示失败 if (p.begin_document(hello.pdf, ) -1) { printf(begin_document failed: %s\n, p.get_errmsg()); return 1; } // A4 纵向595 x 842 点 p.begin_page_ext(595, 842, ); // 加载 Helvetica编码用 winansi大多数西文文本都没问题 int font p.load_font(Helvetica, winansi, ); if (font -1) { printf(load_font failed: %s\n, p.get_errmsg()); return 1; } p.set_font(font, 12); p.fit_textline(Hello from PDFlib 9.1.2, 50, 800, ); p.end_page_ext(); p.end_document(); return 0; }begin_document的第二个参数是文档选项空字符串表示使用默认load_font第三个参数可以用来传字体路径后面在中文环境中会用到。这里没有做任何额外处理编译通过后生成的 hello.pdf 是否带有水印取决于库版本是否被正确授权或清理过。也就是说链接成功只是第一步水印的验证要放到第 3 章。2.3 降级到 VS2010examples.sln 的版本号到底改哪里资源包里的 examples 工程是用 VS2019 保存的如果你只有 VS2010不需要重新创建工程。用记事本打开examples.sln头部通常是这样Microsoft Visual Studio Solution File, Format Version 12.00 # Visual Studio 2019VS2010 对应Microsoft Visual Studio Solution File, Format Version 11.00前 4 行改成Microsoft Visual Studio Solution File, Format Version 11.00 # Visual Studio 2010保存后双击打开即可。这里只提到主 sln 文件各.vcxproj文件里的PlatformToolset是v142VS2010 不识别需要把每个.vcxproj中的PlatformToolsetv142/PlatformToolset换成PlatformToolsetv100/PlatformToolset。这种替换可以用记事本的批量替换完成。降级后最常见的报错是某些 C11 语法不被支持。资源里的 examples 并没有用到特别新的语法主要是std::unique_ptr这类容器VS2010 自带 C0x 部分支持注释掉或换成std::auto_ptr就能过。我一般会在降级前先搜索nullptr把它全部替换为NULL可以省掉近一半的兼容性错误。2.4 链接阶段常见错误对照下面这组错误是配置 PDFlib 时最容易遇到的按错误码或提示信息排查效率最高。错误提示原因处理方式LNK1104: cannot open file pdflib.lib库目录路径没配好确认“附加库目录”指向含 pdflib.lib 的目录LNK2019: unresolved external symbol版本不匹配32位/64位混用检查项目平台与 pdflib.lib 是否同为 x64 或 Win32LNK2038: mismatch detected for RuntimeLibrarylib 使用 /MD 而你用了 /MT在“C/C → 代码生成 → 运行库”中保持一致运行时找不到 pdflib.dllDLL 不在当前目录或 PATH将 bin 目录加入 PATH或复制 DLL 到输出目录其中 RuntimeLibrary 不匹配最隐蔽常见于把 Release 版库链接进 Debug 工程。PDFlib 官方 Windows 版通常使用动态 CRT工程里对应/MD或/MDd如果非要用/MT就需要单独向库厂商索要对应版本。我通常的做法是保持默认/MD只在目标机器上安装对应的 VC Redistributable。注意修改 sln 前先备份原文件改坏了还能快速还原。3. 彻底去水印从许可状态检查到内容流验证水印问题的本质是PDFlib 在未获得合法授权时会进入评估模式生成的文档被嵌入一行文本和一个矩形。文本是www.pdflib.com矩形则是一个用灰色填充的文本框。两者在 PDF 内容流里是两个独立的运算符序列不能混为一谈。3.1 为什么只删字符串会留下水印文本框PDF 内容流本质上是一串图形指令。评估水印在内容流里大致对应两组指令BT /F1 12 Tf 1 0.4 0.4 rg 1 0 0 1 100 700 Tm (www.pdflib.com) Tj ET 1 0 0 rg 100 695 140 15 re f第一段使用Tj输出文本字符串第二段使用re和f画一个填充矩形。矩形颜色通常比文本更淡但视觉上比文本更突兀。如果只把字符串www.pdflib.com替换成空字符串Tj部分没有输出了但re和f依旧存在于是最终 PDF 中央会出现一个颜色很浅的实心矩形。这就是很多人说“去字不去框”的原因。要彻底干净必须确保内容流里同时没有这两段指令。对于编译好的库外部代码很难直接干预 PDFlib 内部的内容流生成有效方式是在代码入口检查库的许可状态再决定是否继续生成文档。下面把两类残留特征列出来方便对照排查。残留类型内容流特征视觉表现检查方式文本水印Tj或TJ中包含 pdflib.com一行小字grep 字符串填充框re f浅色实心矩形grep 矩形指令描边框re S细线框需要渲染确认3.2 在 C 里查询许可状态识别评估模式PDFlib 提供get_option接口读取运行时选项。下面这段代码适合放在begin_document之前char license[1024] {0}; int code p.get_option(license, license, sizeof(license)); if (code 0) { printf(license option: %s\n, license); } else { printf(get_option failed, code%d\n, code); }get_option返回 0 表示成功license缓冲区会返回当前许可证文件的描述文本。如果是评估版返回内容通常包含Evaluation或not licensed字样此时生成的 PDF 就会带水印。如果是已授权或干净处理过的版本license返回的是具体的授权信息例如有效期和产品版本。这里要注意一个常见误区code本身不能代表水印是否存在必须看license缓冲区里的字符串。有些修改版通过补丁把字符串跳过了但license选项仍然返回原始状态更可靠的方式是实际生成一页 PDF再做内容流检查。3.3 生成测试页并检查内容流中的水印特征我在拿到一个新库时会用第 2 章的 hello.pdf 例子生成一页文档然后直接搜索输出文件。Windows 命令行下可以这样findstr /c:www.pdflib.com hello.pdffindstr输出无结果说明字符串层没问题。接着查水印框指令findstr /c:re hello.pdf但这种方式会把坐标轴、字体定义等含re的行也匹配出来误报率较高。更准确的方式是匹配re前后带有rg或f的组合不过 PDF 内容流被 FlateDecode 压缩后findstr并不可靠。我一般先在命令行解压内容流再检查qpdf --qdf --object-streamsdisable hello.pdf hello_decoded.pdf grep -a -E ^[0-9.]\s[0-9.]\s[0-9.]\s[0-9.]\sre\sf hello_decoded.pdf这条grep匹配四个数字加re f的完整矩形填充指令。如果查询结果为空说明内容流里没有借用该语法绘制的水印矩形。需要注意的是并非所有矩形都由这四个数字控制这里针对的是 PDFlib 评估模式最典型的输出格式。3.4 文本框还在的其他可能性另一种常见残留是文本字符串已经被清掉但矩形不是re f而是re S的描边矩形。S表示画轮廓视觉上是一个细线框。所以检查时要把f和S都覆盖到grep -a -E ^[0-9.]\s[0-9.]\s[0-9.]\s[0-9.]\sre\s[fS] hello_decoded.pdf开着反向光看内容流是很累的一件事后面第 5 章会提供一个三层验证的检查清单可以直接落到项目里用。如果你手里的库清掉了水印字符串但没清矩形上面的命令会在第二步就把问题暴露出来。4. Adobe-Japan1-UCS2 与 AFM 字体映射中文 PDF 不花屏的关键4.1 Adobe-Japan1-UCS2 是编码映射不是字体文件资源包里的Adobe-Japan1-UCS2通常是 PDFlib 用于将Adobe-Japan1CID 编码映射到 Unicode 字符集的文件。PDF 的字体机制里字符是以 CID 或字形索引写入内容流的显示 PDF 的一方必须知道如何把这个索引还原成 Unicode 字符才能正确搜索、复制和渲染中文。Adobe-Japan1-UCS2就是提供这种映射的表。很多人在 C 里输出中文时直接调用fit_textline传入 UTF-8 字符串结果 PDF 里显示成问号。一个很常见的原因是没有将字体编码设置为Unicode而winansi只覆盖拉丁字符。正确的做法是让 PDFlib 加载支持 Unicode 的字体名并把 encoding 参数写成Unicode。4.2 AFM 文件在排版中的角色AFMAdobe Font Metrics文件描述字体的宽度、上下左右边距和字符间距。PDFlib 需要这些数值来计算文本的排版宽度。资源包里的TIR_____.AFM和LuciduxSans-Oblique.afm分别是 Times Roman 和 Lucidux Sans Oblique 的字体度量文件。如果缺少与字体对应的 AFMPDFlib 会报Could not find font metric file一类错误。文件对应字体用途TIR_____.AFMTimes Roman可能带有斜体变体西文正文排版LuciduxSans-Oblique.afmLucidux Sans Oblique无衬线斜体Adobe-Japan1-UCS2日本汉字 CID 映射表CJK 字符集映射在 Windows 上安装这套资源时我会把resource/font路径显式传给 PDFlib。初始化时可以使用PDFlib的set_option设置resource路径这样在load_font时就不用每次写绝对路径。4.3 加载中文字体并输出 UTF-8 文本的完整代码下面是加载系统自带中文字体并输出的例子。这里的字体名采用 Windows 常见写法遇到 macOS 需要换成PingFang SC或STSong#include cstdio #include pdflib.hpp int main() { PDFlib p; // 设置资源路径让库可以从指定目录读取 AFM 和 CID 映射 p.set_option(resourcefile{resource/font}, ); if (p.begin_document(chinese.pdf, ) -1) { printf(begin_document failed: %s\n, p.get_errmsg()); return 1; } p.begin_page_ext(595, 842, ); // encoding 指定为 Unicode而不是 winansi int font p.load_font(STSong-Light, Unicode, ); if (font -1) { printf(load_font failed: %s\n, p.get_errmsg()); return 1; } p.set_font(font, 18); // fit_textline 需要把字符串转换为 PDFlib 期望的编码 // 常见做法是 UTF-8 - UTF-16LE再传给 fit_textline p.fit_textline(L中文 PDF 输出测试, 50, 780, ); p.end_page_ext(); p.end_document(); return 0; }这里需要解释一下fit_textline的宽字符版本会接收wchar_t*在 Windows 上wchar_t是 UTF-16LE。PDFlib 内部的Unicode编码就是 UTF-16因此可以把字符串直接传入。如果你拿到的是 UTF-8 字符串需要先做转换项目里我一般用MultiByteToWideChar完成这一步。STSong-Light是 PDFlib 官方资源中常见的中文字体名称如果你的库没有内置会返回-1并提示找不到字体。4.4 字体加载失败时的排查顺序遇到Cannot find font错误时按照下面三个维度排查resourcefile路径是否正确。路径写错AFM 文件和 CID 映射找不到字体自然加载不了。字体名是否匹配 AFM 文件内的名字。AFM 文件开头有FontName字段load_font使用的是那个名字不是 Windows 显示名。打开 AFM 文件用findstr /i FontName查看。encoding 是否有效。PDFlib 支持Unicode、winansi、不同的预定义编码对于 CJK 文本必须用Unicode而不能用winansi。资源包里的Adobe-Japan1-UCS2如果被遗漏中文字符会退化为点阵或乱码。我在实际项目中习惯把它和 AFM 文件放在同一个目录然后通过resourcefile指定该目录这样即使换到别的机器也不需要改代码。5. 验证去水印结果的三层检查法最后这部分落在验证技巧上。已经构建出干净 PDF 后我用三层检查法确认结果。第一层查文本第二层查内容流第三层做渲染。5.1 第一层文本提取把 PDF 交给pdftotext来自 Poppler提取所有文本pdftotext output.pdf output.txt findstr /c:pdflib.com output.txt干净的结果是没有输出。这里注意pdftotext只提取有明确文本映射的字符已经变成曲线或位图的文本不会被提取因此这一层只过滤文本水印。5.2 第二层内容流解压和矩形指令检查使用qpdf解压内容流qpdf --qdf --object-streamsdisable output.pdf decoded.pdf grep -a -E re [fS] decoded.pdf同时查找填充和描边。如果内容流里还有re f或re S但它不是水印框而是页面边框或表格需要人工确认坐标范围。一个快速判断是看这个矩形是否覆盖了大片页面中央区域。5.3 第三层渲染为图片确认视觉效果最直观的是用 Ghostscript 把 PDF 输出为 PNGgswin64c -dNOPAUSE -dBATCH -sDEVICEpng16m -r150 -sOutputFileoutput.png output.pdf渲染出的图片用眼睛扫一遍重点看页面中央是否有浅色矩形或一行不自然的小字。这条验证能覆盖前两层查不出来的半透明对象。三层都通过后把decoded.pdf和output.png作为回归基线放到测试工程里以后每次升级库或改字体都跑一遍这三个命令。干净 PDF 判断完全靠命令行输出不需要打开阅读器。本文还有配套的精品资源点击获取 PDFlib 9.1.2去水印：除了字符串，文本框残留如何彻底清除？
简介面向 C 开发者的 PDFlib 9.1.2 干净去水印版资源用于解决在项目中读写、生成和编辑 PDF 时官方水印干扰输出的问题。与仅剔除字符水印的版本不同该包彻底清除了页面上的 www.pdflib.com 文字及其背后的水印文本框输出背景纯净可放心用于正式文档或二次封装。资源包共 461 个文件压缩后约 53.76MB包含 95 个 PDF 示例文档、63 个 VCXPROJ 工程文件、33 个 C/C 源文件以及 TTF、AFM、OTF 等字体文件和头文件、静态库、动态库等运行依赖同时保留 EXE 可执行文件、PDB 调试符号、SDF 智能感知数据库并附有 JPG/TIF 示例图片与 TXT 说明便于直接运行验证和对照输出效果。作者基于 VS2019 整理了带详细注解的示例工程按说明用记事本修改 sln 版本号即可降级至 VS2010适合需要快速集成 PDF 功能或研究 PDFlib API 调用细节的初中级开发者。目前已有 134 人浏览学习可作为集成 PDF 功能、研究 API 调用流程及排查环境问题的实用参考。1. PDFlib 9.1.2 去水印别只删字符串文本框才是残留重灾区拿到一个 PDFlib 9.1.2 的资源包很多人第一时间会去生成的 PDF 里搜 www.pdflib.com搜到就替换掉。但实际产物里仍然会有一块浅色矩形这就是评估版绘制的水印文本框。只改动文本字符内容流里的矩形绘制指令还在输出照样不干净。这个包解决的问题就是两步都清掉既没有水印字符串也没有水印框。下面从 VS2019 工程配置开始逐步拆解引用方式、字体映射和最后的验证方法如果你需要降级到 VS2010也会说明 sln 版本号怎么改。适合用 C 集成 PDF 生成能力的开发者和维护旧版项目的工程师。2. VS2019/VS2010 下 PDFlib 9.1.2 的编译链接与降级配置在 C 项目里引用 PDFlib通常不是把整个 examples 工程直接搬过来而是单独建一个控制台工程把库路径配好再一个文件一个文件地加代码。这一章先解决环境问题。2.1 库目录里到底哪些文件会被用到先看资源包里与编译相关的核心文件。Windows 下 PDFlib 的二进制分布通常是这样的结构pdflib/9.1.2/ ├── include/pdflib.hpp ├── include/pdflib.h ├── lib/pdflib.lib ├── bin/pdflib.dll ├── resource/font/Adobe-Japan1-UCS2 ├── resource/font/LuciduxSans-Oblique.afm ├── resource/font/TIR_____.AFM └── examples/pdflib.hpp是 C 封装头文件pdflib.h是 C 接口链接时用到pdflib.lib运行期需要pdflib.dll。资源文件里的 AFM 和 Adobe-Japan1-UCS2 则用于字体度量与 CID 映射第 4 章会专门讲。多数编译错误的根源不是代码逻辑而是 DLL 和 LIB 路径没配对LIB 在链接器路径里DLL 在 PATH 里两个位置不一致就会出现“应用程序无法启动”或“无法解析的外部符号”。2.2 新建 VS2019 C 工程并配置库引用我在实际项目中一般建一个空的控制台应用然后手动配置。打开“项目属性”的“VC 目录”“包含目录”添加include文件夹。“库目录”添加lib文件夹。在“链接器 → 输入 → 附加依赖项”里写入pdflib.lib。把pdflib.dll复制到输出目录或直接把bin加入系统 PATH。然后粘贴一个最小生成例子测试链接#include cstdio #include pdflib.hpp int main() { PDFlib p; // 初始化并检查错误码begin_document 返回 -1 表示失败 if (p.begin_document(hello.pdf, ) -1) { printf(begin_document failed: %s\n, p.get_errmsg()); return 1; } // A4 纵向595 x 842 点 p.begin_page_ext(595, 842, ); // 加载 Helvetica编码用 winansi大多数西文文本都没问题 int font p.load_font(Helvetica, winansi, ); if (font -1) { printf(load_font failed: %s\n, p.get_errmsg()); return 1; } p.set_font(font, 12); p.fit_textline(Hello from PDFlib 9.1.2, 50, 800, ); p.end_page_ext(); p.end_document(); return 0; }begin_document的第二个参数是文档选项空字符串表示使用默认load_font第三个参数可以用来传字体路径后面在中文环境中会用到。这里没有做任何额外处理编译通过后生成的 hello.pdf 是否带有水印取决于库版本是否被正确授权或清理过。也就是说链接成功只是第一步水印的验证要放到第 3 章。2.3 降级到 VS2010examples.sln 的版本号到底改哪里资源包里的 examples 工程是用 VS2019 保存的如果你只有 VS2010不需要重新创建工程。用记事本打开examples.sln头部通常是这样Microsoft Visual Studio Solution File, Format Version 12.00 # Visual Studio 2019VS2010 对应Microsoft Visual Studio Solution File, Format Version 11.00前 4 行改成Microsoft Visual Studio Solution File, Format Version 11.00 # Visual Studio 2010保存后双击打开即可。这里只提到主 sln 文件各.vcxproj文件里的PlatformToolset是v142VS2010 不识别需要把每个.vcxproj中的PlatformToolsetv142/PlatformToolset换成PlatformToolsetv100/PlatformToolset。这种替换可以用记事本的批量替换完成。降级后最常见的报错是某些 C11 语法不被支持。资源里的 examples 并没有用到特别新的语法主要是std::unique_ptr这类容器VS2010 自带 C0x 部分支持注释掉或换成std::auto_ptr就能过。我一般会在降级前先搜索nullptr把它全部替换为NULL可以省掉近一半的兼容性错误。2.4 链接阶段常见错误对照下面这组错误是配置 PDFlib 时最容易遇到的按错误码或提示信息排查效率最高。错误提示原因处理方式LNK1104: cannot open file pdflib.lib库目录路径没配好确认“附加库目录”指向含 pdflib.lib 的目录LNK2019: unresolved external symbol版本不匹配32位/64位混用检查项目平台与 pdflib.lib 是否同为 x64 或 Win32LNK2038: mismatch detected for RuntimeLibrarylib 使用 /MD 而你用了 /MT在“C/C → 代码生成 → 运行库”中保持一致运行时找不到 pdflib.dllDLL 不在当前目录或 PATH将 bin 目录加入 PATH或复制 DLL 到输出目录其中 RuntimeLibrary 不匹配最隐蔽常见于把 Release 版库链接进 Debug 工程。PDFlib 官方 Windows 版通常使用动态 CRT工程里对应/MD或/MDd如果非要用/MT就需要单独向库厂商索要对应版本。我通常的做法是保持默认/MD只在目标机器上安装对应的 VC Redistributable。注意修改 sln 前先备份原文件改坏了还能快速还原。3. 彻底去水印从许可状态检查到内容流验证水印问题的本质是PDFlib 在未获得合法授权时会进入评估模式生成的文档被嵌入一行文本和一个矩形。文本是www.pdflib.com矩形则是一个用灰色填充的文本框。两者在 PDF 内容流里是两个独立的运算符序列不能混为一谈。3.1 为什么只删字符串会留下水印文本框PDF 内容流本质上是一串图形指令。评估水印在内容流里大致对应两组指令BT /F1 12 Tf 1 0.4 0.4 rg 1 0 0 1 100 700 Tm (www.pdflib.com) Tj ET 1 0 0 rg 100 695 140 15 re f第一段使用Tj输出文本字符串第二段使用re和f画一个填充矩形。矩形颜色通常比文本更淡但视觉上比文本更突兀。如果只把字符串www.pdflib.com替换成空字符串Tj部分没有输出了但re和f依旧存在于是最终 PDF 中央会出现一个颜色很浅的实心矩形。这就是很多人说“去字不去框”的原因。要彻底干净必须确保内容流里同时没有这两段指令。对于编译好的库外部代码很难直接干预 PDFlib 内部的内容流生成有效方式是在代码入口检查库的许可状态再决定是否继续生成文档。下面把两类残留特征列出来方便对照排查。残留类型内容流特征视觉表现检查方式文本水印Tj或TJ中包含 pdflib.com一行小字grep 字符串填充框re f浅色实心矩形grep 矩形指令描边框re S细线框需要渲染确认3.2 在 C 里查询许可状态识别评估模式PDFlib 提供get_option接口读取运行时选项。下面这段代码适合放在begin_document之前char license[1024] {0}; int code p.get_option(license, license, sizeof(license)); if (code 0) { printf(license option: %s\n, license); } else { printf(get_option failed, code%d\n, code); }get_option返回 0 表示成功license缓冲区会返回当前许可证文件的描述文本。如果是评估版返回内容通常包含Evaluation或not licensed字样此时生成的 PDF 就会带水印。如果是已授权或干净处理过的版本license返回的是具体的授权信息例如有效期和产品版本。这里要注意一个常见误区code本身不能代表水印是否存在必须看license缓冲区里的字符串。有些修改版通过补丁把字符串跳过了但license选项仍然返回原始状态更可靠的方式是实际生成一页 PDF再做内容流检查。3.3 生成测试页并检查内容流中的水印特征我在拿到一个新库时会用第 2 章的 hello.pdf 例子生成一页文档然后直接搜索输出文件。Windows 命令行下可以这样findstr /c:www.pdflib.com hello.pdffindstr输出无结果说明字符串层没问题。接着查水印框指令findstr /c:re hello.pdf但这种方式会把坐标轴、字体定义等含re的行也匹配出来误报率较高。更准确的方式是匹配re前后带有rg或f的组合不过 PDF 内容流被 FlateDecode 压缩后findstr并不可靠。我一般先在命令行解压内容流再检查qpdf --qdf --object-streamsdisable hello.pdf hello_decoded.pdf grep -a -E ^[0-9.]\s[0-9.]\s[0-9.]\s[0-9.]\sre\sf hello_decoded.pdf这条grep匹配四个数字加re f的完整矩形填充指令。如果查询结果为空说明内容流里没有借用该语法绘制的水印矩形。需要注意的是并非所有矩形都由这四个数字控制这里针对的是 PDFlib 评估模式最典型的输出格式。3.4 文本框还在的其他可能性另一种常见残留是文本字符串已经被清掉但矩形不是re f而是re S的描边矩形。S表示画轮廓视觉上是一个细线框。所以检查时要把f和S都覆盖到grep -a -E ^[0-9.]\s[0-9.]\s[0-9.]\s[0-9.]\sre\s[fS] hello_decoded.pdf开着反向光看内容流是很累的一件事后面第 5 章会提供一个三层验证的检查清单可以直接落到项目里用。如果你手里的库清掉了水印字符串但没清矩形上面的命令会在第二步就把问题暴露出来。4. Adobe-Japan1-UCS2 与 AFM 字体映射中文 PDF 不花屏的关键4.1 Adobe-Japan1-UCS2 是编码映射不是字体文件资源包里的Adobe-Japan1-UCS2通常是 PDFlib 用于将Adobe-Japan1CID 编码映射到 Unicode 字符集的文件。PDF 的字体机制里字符是以 CID 或字形索引写入内容流的显示 PDF 的一方必须知道如何把这个索引还原成 Unicode 字符才能正确搜索、复制和渲染中文。Adobe-Japan1-UCS2就是提供这种映射的表。很多人在 C 里输出中文时直接调用fit_textline传入 UTF-8 字符串结果 PDF 里显示成问号。一个很常见的原因是没有将字体编码设置为Unicode而winansi只覆盖拉丁字符。正确的做法是让 PDFlib 加载支持 Unicode 的字体名并把 encoding 参数写成Unicode。4.2 AFM 文件在排版中的角色AFMAdobe Font Metrics文件描述字体的宽度、上下左右边距和字符间距。PDFlib 需要这些数值来计算文本的排版宽度。资源包里的TIR_____.AFM和LuciduxSans-Oblique.afm分别是 Times Roman 和 Lucidux Sans Oblique 的字体度量文件。如果缺少与字体对应的 AFMPDFlib 会报Could not find font metric file一类错误。文件对应字体用途TIR_____.AFMTimes Roman可能带有斜体变体西文正文排版LuciduxSans-Oblique.afmLucidux Sans Oblique无衬线斜体Adobe-Japan1-UCS2日本汉字 CID 映射表CJK 字符集映射在 Windows 上安装这套资源时我会把resource/font路径显式传给 PDFlib。初始化时可以使用PDFlib的set_option设置resource路径这样在load_font时就不用每次写绝对路径。4.3 加载中文字体并输出 UTF-8 文本的完整代码下面是加载系统自带中文字体并输出的例子。这里的字体名采用 Windows 常见写法遇到 macOS 需要换成PingFang SC或STSong#include cstdio #include pdflib.hpp int main() { PDFlib p; // 设置资源路径让库可以从指定目录读取 AFM 和 CID 映射 p.set_option(resourcefile{resource/font}, ); if (p.begin_document(chinese.pdf, ) -1) { printf(begin_document failed: %s\n, p.get_errmsg()); return 1; } p.begin_page_ext(595, 842, ); // encoding 指定为 Unicode而不是 winansi int font p.load_font(STSong-Light, Unicode, ); if (font -1) { printf(load_font failed: %s\n, p.get_errmsg()); return 1; } p.set_font(font, 18); // fit_textline 需要把字符串转换为 PDFlib 期望的编码 // 常见做法是 UTF-8 - UTF-16LE再传给 fit_textline p.fit_textline(L中文 PDF 输出测试, 50, 780, ); p.end_page_ext(); p.end_document(); return 0; }这里需要解释一下fit_textline的宽字符版本会接收wchar_t*在 Windows 上wchar_t是 UTF-16LE。PDFlib 内部的Unicode编码就是 UTF-16因此可以把字符串直接传入。如果你拿到的是 UTF-8 字符串需要先做转换项目里我一般用MultiByteToWideChar完成这一步。STSong-Light是 PDFlib 官方资源中常见的中文字体名称如果你的库没有内置会返回-1并提示找不到字体。4.4 字体加载失败时的排查顺序遇到Cannot find font错误时按照下面三个维度排查resourcefile路径是否正确。路径写错AFM 文件和 CID 映射找不到字体自然加载不了。字体名是否匹配 AFM 文件内的名字。AFM 文件开头有FontName字段load_font使用的是那个名字不是 Windows 显示名。打开 AFM 文件用findstr /i FontName查看。encoding 是否有效。PDFlib 支持Unicode、winansi、不同的预定义编码对于 CJK 文本必须用Unicode而不能用winansi。资源包里的Adobe-Japan1-UCS2如果被遗漏中文字符会退化为点阵或乱码。我在实际项目中习惯把它和 AFM 文件放在同一个目录然后通过resourcefile指定该目录这样即使换到别的机器也不需要改代码。5. 验证去水印结果的三层检查法最后这部分落在验证技巧上。已经构建出干净 PDF 后我用三层检查法确认结果。第一层查文本第二层查内容流第三层做渲染。5.1 第一层文本提取把 PDF 交给pdftotext来自 Poppler提取所有文本pdftotext output.pdf output.txt findstr /c:pdflib.com output.txt干净的结果是没有输出。这里注意pdftotext只提取有明确文本映射的字符已经变成曲线或位图的文本不会被提取因此这一层只过滤文本水印。5.2 第二层内容流解压和矩形指令检查使用qpdf解压内容流qpdf --qdf --object-streamsdisable output.pdf decoded.pdf grep -a -E re [fS] decoded.pdf同时查找填充和描边。如果内容流里还有re f或re S但它不是水印框而是页面边框或表格需要人工确认坐标范围。一个快速判断是看这个矩形是否覆盖了大片页面中央区域。5.3 第三层渲染为图片确认视觉效果最直观的是用 Ghostscript 把 PDF 输出为 PNGgswin64c -dNOPAUSE -dBATCH -sDEVICEpng16m -r150 -sOutputFileoutput.png output.pdf渲染出的图片用眼睛扫一遍重点看页面中央是否有浅色矩形或一行不自然的小字。这条验证能覆盖前两层查不出来的半透明对象。三层都通过后把decoded.pdf和output.png作为回归基线放到测试工程里以后每次升级库或改字体都跑一遍这三个命令。干净 PDF 判断完全靠命令行输出不需要打开阅读器。本文还有配套的精品资源点击获取