简介面向需要在VS2005环境下处理PDF读写的C开发者这是一套已完成移植与联调的PoDoFo 0.9.7工程包。原库依赖freetype、libjpeg、libpng、libtiff、openssl、zlib等第三方组件逐个链接静态库颇为繁琐此处已将依赖编译为lib库用VS打开即可编译通过省去环境搭建的反复试错。包内共1382个文件以h头文件、c与cpp源码、obj中间产物为主另有vcproj与sln工程文件、lib与dll二进制、mk与jamfile构建脚本以及readme、html说明文档整体约42.38MB兼顾源码查阅与直接复用。文档加密由PODOFO_HAVE_OPENSSL宏控制启用后需补充两个dll并链接对应lib两个依赖Linux接口的用例已置为禁用状态。已有572人学习适合具备一定C基础、希望在旧版VS上实现PDF解析与生成的中高级开发者参考。1. 为什么在 2024 年还有人用 VC8 编 PoDoFo 0.9.7一个 PDF 解析库的老工具链落地某公司的老 MFC 报表系统还锁在 VS2005 工具链上客户新提的需求里有一条把系统生成的 PDF 按章节拆开、给每页加水印、再合并回去。选型时试过几个库最后落在 PoDoFo 0.9.7——C 接口干净、能读写加密文档、源码量不大静态链进 exe 不额外带 DLL。真正动手才发现 0.9.7 是照着 C11 写的VC8 编译器不认 nullptr、override、enum class新版本 CMake 也把 Visual Studio 8 2005 生成器删了。这篇记录从依赖库编译、CMake 版本对齐、C11 语法降级到中文 PDF 乱码排查的完整路径适合同样被老工具链绑住、又必须把 PDF 文件解析塞进现有工程的 C 开发者。2. 拆开 PoDoFo 0.9.7 的依赖与编译链路选型、裁剪与 CMake 生成器适配2.1 PoDoFo 0.9.7 在 PDF 库坐标系里的位置先把选型说清楚否则后面每一步裁剪都没有依据。PDFium 渲染最强但它是 Chromium 的一部分拉下来就是几百 MB还要求 C14 以上MuPDF 渲染快、许可证是 AGPL商业闭源项目基本不能碰Poppler 的 C 接口带一堆 Glib 依赖在 Windows 上编过的人都懂那种酸爽libharu 只写不读满足不了拆分的需求。PoDoFo 的定位在中间读写都支持原生 C 面向对象接口LGPL 许可静态库体积能压到几 MB正好适合塞进一个老 MFC 工程。0.9.7 这个版本能覆盖的能力包括PDF 1.7 文档的解析与生成、RC4 40/128 位和 AES-128 位加密文档的读写、增量更新、AcroForm 表单字段访问、字体嵌入与子集化、页面内容流的解析与重写。拆分、合并、加水印、提取文本、填表单这几类需求都在射程内。不足也明显官方文档薄出错时抛的 PdfError 只给一个错误码字体管理在 Windows 上要靠自己注册 ttf中文支持需要额外做功课。我选它还有一个现实原因——源码结构清晰。core 目录负责对象模型和解析器base 目录放流、字符串、编码这些基础设施doc 目录是文档和页面font 目录处理字体。真出问题时能顺着调用栈找到具体文件不像某些库一层套一层模板报错信息全是 instantiating 某某。2.2 依赖裁剪zlib、libjpeg、libtiff、freetype 的取舍PoDoFo 0.9.7 的依赖分成“必须”和“可选”两档先把表列出来再逐个说为什么这么选。依赖作用是否必须建议版本VC8 下的编法zlibFlateDecode 流压缩/解压必须1.2.11nmake win32/Makefile.mscfreetype字体嵌入、子集化、字形度量必须2.8 以前CMake 生成 VS2005 工程libjpegDCTDecode 图片解码按需6b 或 9nmake makefile.vclibtiffCCITTFaxDecode 之外的 TIFF 图片按需4.0.xnmake nmake.optfontconfigLinux 下系统字体查找Windows 关闭-不编OpenSSLAES 加密的底层实现可关1.0.2不编裁剪原则很直接如果只做文本页面的拆分合并和水印zlib freetype 就够文档里有扫描件图片才需要 jpeg/tiff。fontconfig 是 Unix 那套 fontconfig 库Windows 上不存在CMake 里必须显式关掉否则 configure 阶段就会报找不到。OpenSSL 我一般也先关0.9.7 在没有 OpenSSL 时会退回内置的加密实现先让编译链路跑通等加密需求真正压上来再补。对应到 CMake 变量就是PODOFO_HAVE_JPEG_LIB、PODOFO_HAVE_TIFF_LIB、PODOFO_HAVE_PNG_LIB、PODOFO_HAVE_FONTCONFIG、PODOFO_HAVE_OPENSSL这几个开关取值 0 或 1。另外PODOFO_BUILD_LIB_ONLY1一定要开它会把 podofo-tools 那堆命令行工具排除掉少编十几个工程也少踩一批 main 函数里用到的 C11 语法。2.3 CMake 与 VS2005 生成器的版本对齐这是很多人第一步就翻车的地方。CMake 对 Visual Studio 8 2005 的生成器名字是Visual Studio 8 2005注意不是VS2005也不是Visual Studio 2005。从 CMake 4.x 开始这个生成器被彻底移除装最新版连 configure 都过不去。稳妥做法是锁 3.20 到 3.27 之间的版本装完先跑一遍确认cmake --version cmake --help | findstr /C:Visual Studio 8 2005第二条命令能打印出生成器名字才说明这个 CMake 可用。我一般会在工程根目录放一个cmake-version.txt记下具体版本号换机器时照装省得又去猜。还有一点容易忽略VS 是多人称生成器CMAKE_BUILD_TYPE在这种生成器下不生效Debug/Release 是在编译命令里用/p:Configuration或者devenv.com /build Release|Win32指定的。CMake 阶段写-DCMAKE_BUILD_TYPERelease不会报错但也不会起作用第一次编完发现是 Debug 版库多半就是这个原因。2.4 目录与构建脚本落位依赖库、源码、构建目录、输出目录分开放后面排查问题时能一眼看出用的是哪份头文件。我用的结构是这样pdfkit/ deps/ zlib-1.2.11/ jpeg-6b/ tiff-4.0.10/ freetype-2.8/ src/ podofo-0.9.7/ build/ vs2005/ # CMake 生成 .sln 的位置 out/ include/ # 汇总头文件 lib/ # 汇总 .lib vc8_compat.h构建入口脚本只做三件事进 VS2005 环境、切到构建目录、调 CMake。写成build.bat放在根目录echo off call C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat x86 if not exist build\vs2005 mkdir build\vs2005 cd build\vs2005 cmake -G Visual Studio 8 2005 ^ -DPODOFO_BUILD_LIB_ONLY1 ^ -DPODOFO_BUILD_STATIC1 ^ -DPODOFO_BUILD_SHARED0 ^ -DPODOFO_HAVE_FONTCONFIG0 ^ -DPODOFO_HAVE_OPENSSL0 ^ -DCMAKE_INCLUDE_PATH%CD%\..\..\out\include ^ -DCMAKE_LIBRARY_PATH%CD%\..\..\out\lib ^ ..\..\src\podofo-0.9.7vcvarsall.bat x86是为了让 nmake 和 cl 都在 PATH 里32 位是因为老 MFC 工程几乎都是 Win32 目标。CMAKE_INCLUDE_PATH和CMAKE_LIBRARY_PATH指向提前编好的依赖比在 CMake GUI 里一个个填路径可靠得多。3. 用 VS2005 工具链把依赖库先编出来zlib / libjpeg / libtiff / freetype 逐个过3.1 zlib 的 VC8 编译与符号导出zlib 的源码里自带win32/Makefile.msc这是给 nmake 用的比 CMake 更省事也不会引入新版本 CMake 的语法问题。进 VS2005 命令行环境后直接编call C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat x86 cd deps\zlib-1.2.11 nmake -f win32\Makefile.msc编完会得到zlib.lib静态库、zdll.lib导入库和zlib1.dll。PoDoFo 静态链接时用zlib.lib不要错拿zdll.lib否则运行时要带 DLL客户机器上少一个文件就是启动报错。Makefile.msc里默认的CFLAGS含/MD这个必须和后面 PoDoFo 的运行时库保持一致。如果老工程是/MT要么改 Makefile 里的/MD为/MT重编要么在 PoDoFo 侧也改成/MD。我一般选后者因为/MT下静态库重复链接会让 exe 体积翻倍还容易在跨 DLL 传指针时出问题。3.2 libjpeg 与 libtiff 的静态库配置libjpeg 6b 的编译入口是makefile.vc但编之前得先把jconfig.vc复制成jconfig.h并确认里面这几个宏是打开的#define HAVE_STDDEF_H #define HAVE_STDLIB_H #define HAVE_UNSIGNED_CHAR #define HAVE_UNSIGNED_SHORT少一个HAVE_STDLIB_H后面 PoDoFo 引用 jpeg 头文件时就可能报size_t未定义这种报错出现在第三方头文件里第一眼很难联想到是 jconfig 的问题。命令是cd deps\jpeg-6b copy jconfig.vc jconfig.h nmake -f makefile.vc nodebug1nodebug1会编 Release 版本体积小一半。产物是libjpeg.lib。libtiff 稍微麻烦一点得先改nmake.optOPTFLAGS里的/MD保持一致INCLS加上 zlib 和 jpeg 的头文件路径LIBDIR加库路径。改完再cd deps\tiff-4.0.10 nmake -f makefile.vc如果只是做文本 PDF 的拆分合并libjpeg 和 libtiff 都可以先不编CMake 里把对应开关置 0编译时间能省一大截。等真的遇到带扫描图的文档再补避免一开始就被第三方库的错误拖住。3.3 freetype 的 win32 字体方案freetype 的源码里没有现成的 VS2005 工程用 CMake 生成最省事但要挑版本。2.8 之后的源码开始用一些 C99 的写法VC8 编起来报错会多不少我一般锁在 2.8 以前。cd deps\freetype-2.8 mkdir build cd build cmake -G Visual Studio 8 2005 ^ -DCMAKE_INSTALL_PREFIX..\..\..\out ^ -DFT_WITH_ZLIB0 ^ -DFT_WITH_BZIP20 ^ -DFT_WITH_PNG0 ^ -DFT_WITH_HARFBUZZ0 ^ -DFT_WITH_BROTLI0 .. devenv.com freetype.sln /build Release|Win32把 zlib、png、harfbuzz 全关掉是因为 PoDoFo 只用 freetype 做字形度量和子集化用不到这些高级特性关掉能少一堆依赖。编完在objs\release下拿到freetype.lib头文件在include目录。Windows 上没有 fontconfigPoDoFo 的字体查找会退化成“你得自己告诉它 ttf 在哪”。常见做法是在初始化时把C:\Windows\Fonts\simsun.ttc这类字体路径注册进去或者干脆把字体文件随程序发布用相对路径加载。我倾向后者客户机器上字体缺失或版本不一致时至少程序行为是确定的。3.4 依赖目录结构与环境变量四个库编完后把头文件和 lib 汇总到out下CMake 找起来最省心out/ include/ zlib.h, zconf.h jpeglib.h, jconfig.h tiff.h, tiffio.h ft2build.h, freetype/ lib/ zlib.lib libjpeg.lib libtiff.lib freetype.lib汇总这一步别偷懒用xcopy全拷只拷需要的头文件。freetype 的include下面有一堆内部头全拷进去会让编译器的搜索路径变长偶尔还会和系统里的同名头文件撞车。4. PoDoFo 0.9.7 主体编译从 CMake 配置到 .sln 落地的每一步4.1 CMake 参数清单与缓存变量依赖齐了之后configure 这一步的核心是把每个依赖的开关和路径喂给 CMake。完整命令如下cmake -G Visual Studio 8 2005 ^ -DPODOFO_BUILD_LIB_ONLY1 ^ -DPODOFO_BUILD_STATIC1 ^ -DPODOFO_BUILD_SHARED0 ^ -DPODOFO_HAVE_JPEG_LIB0 ^ -DPODOFO_HAVE_TIFF_LIB0 ^ -DPODOFO_HAVE_PNG_LIB0 ^ -DPODOFO_HAVE_FONTCONFIG0 ^ -DPODOFO_HAVE_OPENSSL0 ^ -DCMAKE_INCLUDE_PATH%CD%\..\..\out\include ^ -DCMAKE_LIBRARY_PATH%CD%\..\..\out\lib ^ -DCMAKE_CXX_FLAGS/D_CRT_SECURE_NO_WARNINGS /FI\vc8_compat.h\ ^ ..\..\src\podofo-0.9.7每个参数的作用PODOFO_BUILD_LIB_ONLY只编库不编工具PODOFO_BUILD_STATIC出静态库PODOFO_HAVE_*控制可选依赖CMAKE_INCLUDE_PATH/CMAKE_LIBRARY_PATH是 CMake 的查找提示路径比FindXXX.cmake里写死路径灵活CMAKE_CXX_FLAGS里的/FI是强制包含把兼容头塞进每个编译单元省得手工改几十个 cpp 的 include。configure 完成后看CMakeCache.txt里的PODOFO_HAVE_ZLIB和PODOFO_HAVE_FREETYPE是不是 1这两个是必须项如果是 0 说明路径没找对后面必然链接失败。4.2 头文件与 C11 差异stdint.h、override、nullptr 的补丁策略VC8 缺的东西集中在两处C99 的stdint.h和 C11 的关键字/库设施。前者好办后者要写兼容头。我的vc8_compat.h大致长这样// vc8_compat.hVC8 缺失的 C99/C11 符号兜底 #if defined(_MSC_VER) _MSC_VER 1600 // 1. stdint.h 的替代VC8 自带的是 Windows SDK 里的版本不一定在默认路径 #ifndef _STDINT_H typedef signed __int64 int64_t; typedef unsigned __int64 uint64_t; typedef signed int int32_t; typedef unsigned int uint32_t; typedef signed short int16_t; typedef unsigned short uint16_t; typedef signed char int8_t; typedef unsigned char uint8_t; #endif // 2. C11 关键字降级 #ifndef nullptr #define nullptr NULL #endif #ifndef override #define override #endif // 3. snprintf / va_copy 在 VC8 里不存在 #ifndef snprintf #define snprintf _snprintf #endif #ifndef va_copy #define va_copy(dst, src) ((dst) (src)) #endif #endif // _MSC_VER 1600nullptr在 VC8 里不是关键字也不是保留字除非开/clrPoDoFo 不开所以#define nullptr NULL是安全的。override同理它只是一个标识符宏定义成空之后所有void f() override;都能正常编译。_snprintf和snprintf的返回值语义不同_snprintf在截断时不保证以\0结尾但 PoDoFo 里这个函数主要用在日志和错误信息拼接风险可以接受如果介意可以自己包一个保证结尾的podofo_snprintf。真正麻烦的是enum class和std::unique_ptr。enum class在 VC8 里直接报 C2059只能改成普通 enum 再手工限定作用域0.9.7 里用到的地方不算多一处处改半天能过。std::unique_ptr没有现成替代auto_ptr的语义接近但不支持数组和移动我一般是把成员变量里的unique_ptr换成裸指针加析构 delete局部变量里的换成auto_ptr。这一步没有捷径改完编译一遍看链接错误定位漏网之鱼。4.3 编译错误逐类排查从 time_t 到 snprintf第一次编报几百个错是正常的按错误码归类能快很多。下面这张表是我实际遇到过的几类错误码典型信息原因处理C2065nullptr未声明兼容头没生效检查/FI路径或直接在项目属性里加强制包含C2059enum后跟classC11 的 enum class改普通 enum 手工限定C3861找不到va_copyVC8 无此宏compat 头里用赋值替代C2039unique_ptr不是std成员C11 库设施换裸指针或auto_ptrC4996strcpy不安全VC8 的 CRT 安全检查加/D_CRT_SECURE_NO_WARNINGSLNK2019__imp__inflate未解析zlib 没链或 CRT 不一致检查 zlib.lib 的编译选项C4996 这类警告不用一个个改代码/D_CRT_SECURE_NO_WARNINGS一关就行老代码里这种调用成百上千改是改不完的。LNK2019 集中在__imp__开头的符号时基本可以断定是“静态库当导入库用”或者“运行时库不一致”回到 3.1 节检查 zlib 的编译选项。4.4 生成 lib 与头文件整理configure 通过、语法错误清完之后用 devenv 命令行编译devenv.com podofo.sln /build Release|Win32 /project podofo/project podofo只编库工程跳过依赖的其他子工程速度快很多。产物在build\vs2005\src\Release\podofo.lib具体路径看 CMakeLists 里的输出目录设置不同小版本可能差一层。头文件在src\podofo-0.9.7\src下按base、core、doc、font分目录用的时候把整个src目录加到包含路径代码里写#include podofo/podofo.h。我一般还会把podofo.lib、podofo_d.lib如果编了 Debug和头文件一起拷到out下再写一个podofo.pc或者简单的readme.txt记录版本和编译选项。过三个月再回来查“这个 lib 到底带不带 jpeg”没有记录就只能重新编一遍试。5. 避坑与排查VC8 编译 PoDoFo 常见的五个翻车现场5.1 LNK2019CRT 与符号导出不一致现象主工程链接podofo.lib时报一串__imp__inflate、__imp__jpeg_read_header未解析但库文件明明在附加依赖里。原因依赖库和主工程的运行时库不一致或者把导入库zdll.lib当成了静态库zlib.lib。__imp__前缀是导入库的特征说明链接器认为这些符号要从 DLL 导入。解决统一所有库的/MD或/MT在附加依赖里按podofo.lib → freetype.lib → zlib.lib的顺序排被依赖的放后面用dumpbin /symbols zlib.lib | findstr inflate确认拿到的是静态符号而不是__imp__。5.2 C2059 / C2065C11 语法在 VC8 里的连锁报错现象一编译几百个错误集中在nullptr、override、enum class上改完一个文件又冒出十个。原因/FIvc8_compat.h没生效或者兼容头被放在了stdafx.h之后预处理顺序不对enum class的报错则会连锁触发后面的语法解析失败。解决在项目属性 → C/C → 高级 → 强制包含里直接加文件名比 CMake 的CMAKE_CXX_FLAGS更可靠enum class集中改完再编不要边改边编否则报错数量会一直误导你。5.3 生成 PDF 后 Acrobat 报文件损坏现象用PdfStreamedDocument生成的 PDFPoDoFo 自己读没问题Acrobat 打开提示“文件已损坏”换 Foxit 也一样。原因流式写入要求对象按严格顺序落盘先写页面再回头补资源、或者跨页共享对象都会让 xref 的偏移算错另一种情况是对象没Close()程序就退出了文件尾部缺startxref。解决几十 MB 以内的文档改用PdfMemDocument内存里组织完一次性Save()不依赖写入顺序必须流式时保证对象创建顺序和写入顺序一致析构前显式Close()并在Close()之后检查文件大小是否非零。5.4 加密 PDF 打开抛 PdfError现象PdfMemDocument::Load()构造时抛PdfErrorGetError()返回InvalidPassword但密码明明是对的。原因0.9.7 只支持 Standard Security Handler 的 R2 到 R4RC4 和 AES-128PDF 2.0 的 AES-256R6不在支持范围另一种情况是密码字符串编码不对中文密码按 UTF-8 传进去会被当成 Latin-1。解决先用别的工具确认文档的加密算法版本R6 的文档在上游解密或换库密码用PdfPassword对象构造明确指定编码不要直接传const char*。5.5 中文提取乱码与字体注册现象PdfPage::ExtractText()拿到的中文全是问号或方块英文正常。原因文档里的 CID 字体没有/ToUnicodeCMapPoDoFo 只能按字体编码回退Identity-H 编码下拿到的就是字形索引而不是 Unicode。解决先看PdfFont能不能拿到 ToUnicode 流拿不到就自己解析/ToUnicode的 CMap 做映射生成端则要保证嵌入字体时写入 ToUnicodePdfFont创建时把 ePdfFont_W本文还有配套的精品资源点击获取
简介面向需要在VS2005环境下处理PDF读写的C开发者这是一套已完成移植与联调的PoDoFo 0.9.7工程包。原库依赖freetype、libjpeg、libpng、libtiff、openssl、zlib等第三方组件逐个链接静态库颇为繁琐此处已将依赖编译为lib库用VS打开即可编译通过省去环境搭建的反复试错。包内共1382个文件以h头文件、c与cpp源码、obj中间产物为主另有vcproj与sln工程文件、lib与dll二进制、mk与jamfile构建脚本以及readme、html说明文档整体约42.38MB兼顾源码查阅与直接复用。文档加密由PODOFO_HAVE_OPENSSL宏控制启用后需补充两个dll并链接对应lib两个依赖Linux接口的用例已置为禁用状态。已有572人学习适合具备一定C基础、希望在旧版VS上实现PDF解析与生成的中高级开发者参考。1. 为什么在 2024 年还有人用 VC8 编 PoDoFo 0.9.7一个 PDF 解析库的老工具链落地某公司的老 MFC 报表系统还锁在 VS2005 工具链上客户新提的需求里有一条把系统生成的 PDF 按章节拆开、给每页加水印、再合并回去。选型时试过几个库最后落在 PoDoFo 0.9.7——C 接口干净、能读写加密文档、源码量不大静态链进 exe 不额外带 DLL。真正动手才发现 0.9.7 是照着 C11 写的VC8 编译器不认 nullptr、override、enum class新版本 CMake 也把 Visual Studio 8 2005 生成器删了。这篇记录从依赖库编译、CMake 版本对齐、C11 语法降级到中文 PDF 乱码排查的完整路径适合同样被老工具链绑住、又必须把 PDF 文件解析塞进现有工程的 C 开发者。2. 拆开 PoDoFo 0.9.7 的依赖与编译链路选型、裁剪与 CMake 生成器适配2.1 PoDoFo 0.9.7 在 PDF 库坐标系里的位置先把选型说清楚否则后面每一步裁剪都没有依据。PDFium 渲染最强但它是 Chromium 的一部分拉下来就是几百 MB还要求 C14 以上MuPDF 渲染快、许可证是 AGPL商业闭源项目基本不能碰Poppler 的 C 接口带一堆 Glib 依赖在 Windows 上编过的人都懂那种酸爽libharu 只写不读满足不了拆分的需求。PoDoFo 的定位在中间读写都支持原生 C 面向对象接口LGPL 许可静态库体积能压到几 MB正好适合塞进一个老 MFC 工程。0.9.7 这个版本能覆盖的能力包括PDF 1.7 文档的解析与生成、RC4 40/128 位和 AES-128 位加密文档的读写、增量更新、AcroForm 表单字段访问、字体嵌入与子集化、页面内容流的解析与重写。拆分、合并、加水印、提取文本、填表单这几类需求都在射程内。不足也明显官方文档薄出错时抛的 PdfError 只给一个错误码字体管理在 Windows 上要靠自己注册 ttf中文支持需要额外做功课。我选它还有一个现实原因——源码结构清晰。core 目录负责对象模型和解析器base 目录放流、字符串、编码这些基础设施doc 目录是文档和页面font 目录处理字体。真出问题时能顺着调用栈找到具体文件不像某些库一层套一层模板报错信息全是 instantiating 某某。2.2 依赖裁剪zlib、libjpeg、libtiff、freetype 的取舍PoDoFo 0.9.7 的依赖分成“必须”和“可选”两档先把表列出来再逐个说为什么这么选。依赖作用是否必须建议版本VC8 下的编法zlibFlateDecode 流压缩/解压必须1.2.11nmake win32/Makefile.mscfreetype字体嵌入、子集化、字形度量必须2.8 以前CMake 生成 VS2005 工程libjpegDCTDecode 图片解码按需6b 或 9nmake makefile.vclibtiffCCITTFaxDecode 之外的 TIFF 图片按需4.0.xnmake nmake.optfontconfigLinux 下系统字体查找Windows 关闭-不编OpenSSLAES 加密的底层实现可关1.0.2不编裁剪原则很直接如果只做文本页面的拆分合并和水印zlib freetype 就够文档里有扫描件图片才需要 jpeg/tiff。fontconfig 是 Unix 那套 fontconfig 库Windows 上不存在CMake 里必须显式关掉否则 configure 阶段就会报找不到。OpenSSL 我一般也先关0.9.7 在没有 OpenSSL 时会退回内置的加密实现先让编译链路跑通等加密需求真正压上来再补。对应到 CMake 变量就是PODOFO_HAVE_JPEG_LIB、PODOFO_HAVE_TIFF_LIB、PODOFO_HAVE_PNG_LIB、PODOFO_HAVE_FONTCONFIG、PODOFO_HAVE_OPENSSL这几个开关取值 0 或 1。另外PODOFO_BUILD_LIB_ONLY1一定要开它会把 podofo-tools 那堆命令行工具排除掉少编十几个工程也少踩一批 main 函数里用到的 C11 语法。2.3 CMake 与 VS2005 生成器的版本对齐这是很多人第一步就翻车的地方。CMake 对 Visual Studio 8 2005 的生成器名字是Visual Studio 8 2005注意不是VS2005也不是Visual Studio 2005。从 CMake 4.x 开始这个生成器被彻底移除装最新版连 configure 都过不去。稳妥做法是锁 3.20 到 3.27 之间的版本装完先跑一遍确认cmake --version cmake --help | findstr /C:Visual Studio 8 2005第二条命令能打印出生成器名字才说明这个 CMake 可用。我一般会在工程根目录放一个cmake-version.txt记下具体版本号换机器时照装省得又去猜。还有一点容易忽略VS 是多人称生成器CMAKE_BUILD_TYPE在这种生成器下不生效Debug/Release 是在编译命令里用/p:Configuration或者devenv.com /build Release|Win32指定的。CMake 阶段写-DCMAKE_BUILD_TYPERelease不会报错但也不会起作用第一次编完发现是 Debug 版库多半就是这个原因。2.4 目录与构建脚本落位依赖库、源码、构建目录、输出目录分开放后面排查问题时能一眼看出用的是哪份头文件。我用的结构是这样pdfkit/ deps/ zlib-1.2.11/ jpeg-6b/ tiff-4.0.10/ freetype-2.8/ src/ podofo-0.9.7/ build/ vs2005/ # CMake 生成 .sln 的位置 out/ include/ # 汇总头文件 lib/ # 汇总 .lib vc8_compat.h构建入口脚本只做三件事进 VS2005 环境、切到构建目录、调 CMake。写成build.bat放在根目录echo off call C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat x86 if not exist build\vs2005 mkdir build\vs2005 cd build\vs2005 cmake -G Visual Studio 8 2005 ^ -DPODOFO_BUILD_LIB_ONLY1 ^ -DPODOFO_BUILD_STATIC1 ^ -DPODOFO_BUILD_SHARED0 ^ -DPODOFO_HAVE_FONTCONFIG0 ^ -DPODOFO_HAVE_OPENSSL0 ^ -DCMAKE_INCLUDE_PATH%CD%\..\..\out\include ^ -DCMAKE_LIBRARY_PATH%CD%\..\..\out\lib ^ ..\..\src\podofo-0.9.7vcvarsall.bat x86是为了让 nmake 和 cl 都在 PATH 里32 位是因为老 MFC 工程几乎都是 Win32 目标。CMAKE_INCLUDE_PATH和CMAKE_LIBRARY_PATH指向提前编好的依赖比在 CMake GUI 里一个个填路径可靠得多。3. 用 VS2005 工具链把依赖库先编出来zlib / libjpeg / libtiff / freetype 逐个过3.1 zlib 的 VC8 编译与符号导出zlib 的源码里自带win32/Makefile.msc这是给 nmake 用的比 CMake 更省事也不会引入新版本 CMake 的语法问题。进 VS2005 命令行环境后直接编call C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat x86 cd deps\zlib-1.2.11 nmake -f win32\Makefile.msc编完会得到zlib.lib静态库、zdll.lib导入库和zlib1.dll。PoDoFo 静态链接时用zlib.lib不要错拿zdll.lib否则运行时要带 DLL客户机器上少一个文件就是启动报错。Makefile.msc里默认的CFLAGS含/MD这个必须和后面 PoDoFo 的运行时库保持一致。如果老工程是/MT要么改 Makefile 里的/MD为/MT重编要么在 PoDoFo 侧也改成/MD。我一般选后者因为/MT下静态库重复链接会让 exe 体积翻倍还容易在跨 DLL 传指针时出问题。3.2 libjpeg 与 libtiff 的静态库配置libjpeg 6b 的编译入口是makefile.vc但编之前得先把jconfig.vc复制成jconfig.h并确认里面这几个宏是打开的#define HAVE_STDDEF_H #define HAVE_STDLIB_H #define HAVE_UNSIGNED_CHAR #define HAVE_UNSIGNED_SHORT少一个HAVE_STDLIB_H后面 PoDoFo 引用 jpeg 头文件时就可能报size_t未定义这种报错出现在第三方头文件里第一眼很难联想到是 jconfig 的问题。命令是cd deps\jpeg-6b copy jconfig.vc jconfig.h nmake -f makefile.vc nodebug1nodebug1会编 Release 版本体积小一半。产物是libjpeg.lib。libtiff 稍微麻烦一点得先改nmake.optOPTFLAGS里的/MD保持一致INCLS加上 zlib 和 jpeg 的头文件路径LIBDIR加库路径。改完再cd deps\tiff-4.0.10 nmake -f makefile.vc如果只是做文本 PDF 的拆分合并libjpeg 和 libtiff 都可以先不编CMake 里把对应开关置 0编译时间能省一大截。等真的遇到带扫描图的文档再补避免一开始就被第三方库的错误拖住。3.3 freetype 的 win32 字体方案freetype 的源码里没有现成的 VS2005 工程用 CMake 生成最省事但要挑版本。2.8 之后的源码开始用一些 C99 的写法VC8 编起来报错会多不少我一般锁在 2.8 以前。cd deps\freetype-2.8 mkdir build cd build cmake -G Visual Studio 8 2005 ^ -DCMAKE_INSTALL_PREFIX..\..\..\out ^ -DFT_WITH_ZLIB0 ^ -DFT_WITH_BZIP20 ^ -DFT_WITH_PNG0 ^ -DFT_WITH_HARFBUZZ0 ^ -DFT_WITH_BROTLI0 .. devenv.com freetype.sln /build Release|Win32把 zlib、png、harfbuzz 全关掉是因为 PoDoFo 只用 freetype 做字形度量和子集化用不到这些高级特性关掉能少一堆依赖。编完在objs\release下拿到freetype.lib头文件在include目录。Windows 上没有 fontconfigPoDoFo 的字体查找会退化成“你得自己告诉它 ttf 在哪”。常见做法是在初始化时把C:\Windows\Fonts\simsun.ttc这类字体路径注册进去或者干脆把字体文件随程序发布用相对路径加载。我倾向后者客户机器上字体缺失或版本不一致时至少程序行为是确定的。3.4 依赖目录结构与环境变量四个库编完后把头文件和 lib 汇总到out下CMake 找起来最省心out/ include/ zlib.h, zconf.h jpeglib.h, jconfig.h tiff.h, tiffio.h ft2build.h, freetype/ lib/ zlib.lib libjpeg.lib libtiff.lib freetype.lib汇总这一步别偷懒用xcopy全拷只拷需要的头文件。freetype 的include下面有一堆内部头全拷进去会让编译器的搜索路径变长偶尔还会和系统里的同名头文件撞车。4. PoDoFo 0.9.7 主体编译从 CMake 配置到 .sln 落地的每一步4.1 CMake 参数清单与缓存变量依赖齐了之后configure 这一步的核心是把每个依赖的开关和路径喂给 CMake。完整命令如下cmake -G Visual Studio 8 2005 ^ -DPODOFO_BUILD_LIB_ONLY1 ^ -DPODOFO_BUILD_STATIC1 ^ -DPODOFO_BUILD_SHARED0 ^ -DPODOFO_HAVE_JPEG_LIB0 ^ -DPODOFO_HAVE_TIFF_LIB0 ^ -DPODOFO_HAVE_PNG_LIB0 ^ -DPODOFO_HAVE_FONTCONFIG0 ^ -DPODOFO_HAVE_OPENSSL0 ^ -DCMAKE_INCLUDE_PATH%CD%\..\..\out\include ^ -DCMAKE_LIBRARY_PATH%CD%\..\..\out\lib ^ -DCMAKE_CXX_FLAGS/D_CRT_SECURE_NO_WARNINGS /FI\vc8_compat.h\ ^ ..\..\src\podofo-0.9.7每个参数的作用PODOFO_BUILD_LIB_ONLY只编库不编工具PODOFO_BUILD_STATIC出静态库PODOFO_HAVE_*控制可选依赖CMAKE_INCLUDE_PATH/CMAKE_LIBRARY_PATH是 CMake 的查找提示路径比FindXXX.cmake里写死路径灵活CMAKE_CXX_FLAGS里的/FI是强制包含把兼容头塞进每个编译单元省得手工改几十个 cpp 的 include。configure 完成后看CMakeCache.txt里的PODOFO_HAVE_ZLIB和PODOFO_HAVE_FREETYPE是不是 1这两个是必须项如果是 0 说明路径没找对后面必然链接失败。4.2 头文件与 C11 差异stdint.h、override、nullptr 的补丁策略VC8 缺的东西集中在两处C99 的stdint.h和 C11 的关键字/库设施。前者好办后者要写兼容头。我的vc8_compat.h大致长这样// vc8_compat.hVC8 缺失的 C99/C11 符号兜底 #if defined(_MSC_VER) _MSC_VER 1600 // 1. stdint.h 的替代VC8 自带的是 Windows SDK 里的版本不一定在默认路径 #ifndef _STDINT_H typedef signed __int64 int64_t; typedef unsigned __int64 uint64_t; typedef signed int int32_t; typedef unsigned int uint32_t; typedef signed short int16_t; typedef unsigned short uint16_t; typedef signed char int8_t; typedef unsigned char uint8_t; #endif // 2. C11 关键字降级 #ifndef nullptr #define nullptr NULL #endif #ifndef override #define override #endif // 3. snprintf / va_copy 在 VC8 里不存在 #ifndef snprintf #define snprintf _snprintf #endif #ifndef va_copy #define va_copy(dst, src) ((dst) (src)) #endif #endif // _MSC_VER 1600nullptr在 VC8 里不是关键字也不是保留字除非开/clrPoDoFo 不开所以#define nullptr NULL是安全的。override同理它只是一个标识符宏定义成空之后所有void f() override;都能正常编译。_snprintf和snprintf的返回值语义不同_snprintf在截断时不保证以\0结尾但 PoDoFo 里这个函数主要用在日志和错误信息拼接风险可以接受如果介意可以自己包一个保证结尾的podofo_snprintf。真正麻烦的是enum class和std::unique_ptr。enum class在 VC8 里直接报 C2059只能改成普通 enum 再手工限定作用域0.9.7 里用到的地方不算多一处处改半天能过。std::unique_ptr没有现成替代auto_ptr的语义接近但不支持数组和移动我一般是把成员变量里的unique_ptr换成裸指针加析构 delete局部变量里的换成auto_ptr。这一步没有捷径改完编译一遍看链接错误定位漏网之鱼。4.3 编译错误逐类排查从 time_t 到 snprintf第一次编报几百个错是正常的按错误码归类能快很多。下面这张表是我实际遇到过的几类错误码典型信息原因处理C2065nullptr未声明兼容头没生效检查/FI路径或直接在项目属性里加强制包含C2059enum后跟classC11 的 enum class改普通 enum 手工限定C3861找不到va_copyVC8 无此宏compat 头里用赋值替代C2039unique_ptr不是std成员C11 库设施换裸指针或auto_ptrC4996strcpy不安全VC8 的 CRT 安全检查加/D_CRT_SECURE_NO_WARNINGSLNK2019__imp__inflate未解析zlib 没链或 CRT 不一致检查 zlib.lib 的编译选项C4996 这类警告不用一个个改代码/D_CRT_SECURE_NO_WARNINGS一关就行老代码里这种调用成百上千改是改不完的。LNK2019 集中在__imp__开头的符号时基本可以断定是“静态库当导入库用”或者“运行时库不一致”回到 3.1 节检查 zlib 的编译选项。4.4 生成 lib 与头文件整理configure 通过、语法错误清完之后用 devenv 命令行编译devenv.com podofo.sln /build Release|Win32 /project podofo/project podofo只编库工程跳过依赖的其他子工程速度快很多。产物在build\vs2005\src\Release\podofo.lib具体路径看 CMakeLists 里的输出目录设置不同小版本可能差一层。头文件在src\podofo-0.9.7\src下按base、core、doc、font分目录用的时候把整个src目录加到包含路径代码里写#include podofo/podofo.h。我一般还会把podofo.lib、podofo_d.lib如果编了 Debug和头文件一起拷到out下再写一个podofo.pc或者简单的readme.txt记录版本和编译选项。过三个月再回来查“这个 lib 到底带不带 jpeg”没有记录就只能重新编一遍试。5. 避坑与排查VC8 编译 PoDoFo 常见的五个翻车现场5.1 LNK2019CRT 与符号导出不一致现象主工程链接podofo.lib时报一串__imp__inflate、__imp__jpeg_read_header未解析但库文件明明在附加依赖里。原因依赖库和主工程的运行时库不一致或者把导入库zdll.lib当成了静态库zlib.lib。__imp__前缀是导入库的特征说明链接器认为这些符号要从 DLL 导入。解决统一所有库的/MD或/MT在附加依赖里按podofo.lib → freetype.lib → zlib.lib的顺序排被依赖的放后面用dumpbin /symbols zlib.lib | findstr inflate确认拿到的是静态符号而不是__imp__。5.2 C2059 / C2065C11 语法在 VC8 里的连锁报错现象一编译几百个错误集中在nullptr、override、enum class上改完一个文件又冒出十个。原因/FIvc8_compat.h没生效或者兼容头被放在了stdafx.h之后预处理顺序不对enum class的报错则会连锁触发后面的语法解析失败。解决在项目属性 → C/C → 高级 → 强制包含里直接加文件名比 CMake 的CMAKE_CXX_FLAGS更可靠enum class集中改完再编不要边改边编否则报错数量会一直误导你。5.3 生成 PDF 后 Acrobat 报文件损坏现象用PdfStreamedDocument生成的 PDFPoDoFo 自己读没问题Acrobat 打开提示“文件已损坏”换 Foxit 也一样。原因流式写入要求对象按严格顺序落盘先写页面再回头补资源、或者跨页共享对象都会让 xref 的偏移算错另一种情况是对象没Close()程序就退出了文件尾部缺startxref。解决几十 MB 以内的文档改用PdfMemDocument内存里组织完一次性Save()不依赖写入顺序必须流式时保证对象创建顺序和写入顺序一致析构前显式Close()并在Close()之后检查文件大小是否非零。5.4 加密 PDF 打开抛 PdfError现象PdfMemDocument::Load()构造时抛PdfErrorGetError()返回InvalidPassword但密码明明是对的。原因0.9.7 只支持 Standard Security Handler 的 R2 到 R4RC4 和 AES-128PDF 2.0 的 AES-256R6不在支持范围另一种情况是密码字符串编码不对中文密码按 UTF-8 传进去会被当成 Latin-1。解决先用别的工具确认文档的加密算法版本R6 的文档在上游解密或换库密码用PdfPassword对象构造明确指定编码不要直接传const char*。5.5 中文提取乱码与字体注册现象PdfPage::ExtractText()拿到的中文全是问号或方块英文正常。原因文档里的 CID 字体没有/ToUnicodeCMapPoDoFo 只能按字体编码回退Identity-H 编码下拿到的就是字形索引而不是 Unicode。解决先看PdfFont能不能拿到 ToUnicode 流拿不到就自己解析/ToUnicode的 CMap 做映射生成端则要保证嵌入字体时写入 ToUnicodePdfFont创建时把 ePdfFont_W本文还有配套的精品资源点击获取
