iTextSharp 4.1.6 和 5.x 版本之间的区别

Question

我们正在开发一个与我们的系统一起使用的 Pdf 解析器。 要求是，我们将所有信息存储在任何 pdf 文档上，并且应该能够复制该文档（与原始文档的更改最少）。

我们进行了一些谷歌搜索，发现 iTextSharp 是实现我们目标的最佳伙伴。 我们正在使用 .net 开发我们的项目。

您可能已经猜到了，正如我在标题中提到的，需要比较特定版本的 iTextSharp（4.1.6 与 5.x）。我们知道 4.1.6 是具有 LGPL/MPL 许可证的 iTextSharp 的最后一个版本。 5.x 版本是 AGPL。

我们希望在选择 LGPL 版本或购买 AGPL 许可证之前对版本进行很好的比较（我们不喜欢发布我们的代码）。

我浏览了 iTextSharp 中的修订更改，但我想知道是否存在任何内容，以便在版本之间进行很好的比较。

提前致谢！

Answer 1

我是iText Software 的CTO，所以就像Michaël 已经在评论区answered 一样，我同时是最权威的消息来源，也是一个有偏见的人 em> 来源。

有一个很简单的对比图on the iText web site。

此图表不包括文本提取，因此请允许我列出自 iText 5 以来的相关改进。

你可能还找到了this page。

如果您想了解有关文本解析的错误修复和性能改进，这是一个更详尽的列表：

• 5.0.0：文本提取：大修以在用户空间中执行计算。这允许解析器正确地确定换行符，即使文本或页面被旋转。
• 5.0.1：重构回调，因此方法签名不需要随着渲染回调 API 的发展而改变。
• 5.0.1：重构以使外部用户更容易与内容流处理器交互。还重构了渲染侦听器，因此文本和图像事件侦听发生在同一个界面中（减少了很多非增值复杂性）
• 5.0.1：文本渲染器的新过滤功能。
• 5.0.1：用于预览 PDF 内容的附加实用方法。
• 5.0.1：添加了更高级的文本渲染器侦听器，可以根据页面上文本的物理位置重建页面内容
• 5.0.1：增加了对 XObject 表单处理的支持（现在可以解析通过 PdfTemplate 添加的文本）
• 5.0.1：添加了对 XObject Image 回调的基本支持
• 5.0.1：错误修复 - 某些页面方向的文本提取不正确
• 5.0.1：错误修复 - 矩阵以错误的顺序连接。
• 5.0.1：PdfTextExtractor：更改了默认渲染侦听器（新的位置感知策略）
• 5.0.1：GraphicsState 的吸气剂
• 5.0.2：对文本提取功能的接口进行重大重构：例如引入类 PdfReaderContentParser
• 5.0.2：CMapAwareDocumentFont：调整以使处理准无效的 PDF 文件更加健壮
• 5.0.2：PdfContentReaderTool：空指针处理，加上一些放置良好的刷新调用
• 5.0.2：PdfContentReaderTool：显示资源条目的详细信息
• 5.0.2：PdfContentStreamProcessor：调整嵌入图像不会导致解析问题并改进 EI 检测
• 5.0.2：LocationTextExtractionStrategy：固定反并行算法，加上负字符​​间偏移。更改为首先构建文本模型，然后计算连接要求的文本提取策略。
• 5.0.2：调整线段实施；优化布鲁诺对文本提取所做的更改；例如：MarkedContentInfo 类的介绍。
• 5.0.2：对文本提取功能的接口进行重大重构：例如引入类 PdfReaderContentParser
• 5.0.3：添加了以用户为单位获取图像区域的方法
• 5.0.3：更好地解析内嵌图像
• 5.0.3：在解析 ToUnicode 流时添加对开始/结束序列的额外检查。
• 5.0.4：数组中的内容流应该像被空格分隔一样被解析
• 5.0.4：公开 CTM
• 5.0.4：重构以将内联图像处理拉入它自己的类。如果未应用过滤器，则添加对图像数据的解析（在某些 PDF 中，图像数据的末尾和 EI 运算符之间没有空格）。最终，最好实际解析图像数据，但这需要对 iText 解码器进行相当大的重构（使用流而不是已知长度的 byte[]）。
• 5.0.4：处理多级过滤器；更正了将空白作为内联图像流的第一个字节的错误。
• 5.0.4：将流过滤器应用于内联图像。
• 5.0.4：PdfReader：为任意字节数组（而不仅仅是流）公开过滤器解码器
• 5.0.6：CMapParser：修复读取损坏的 ToUnicode cmap。
• 5.0.6：处理稍微畸形的嵌入图像
• 5.0.6：CMapAwareDocumentFont：某些 PDF 的差异图大于 256 个字符。
• 5.0.6：性能：缓存文本提取中使用的字体
• 5.1.2：PRTokeniser：使查找 startxref 的算法更节省内存。
• 5.1.2：RandomAccessFileOrArray：改进了对无法映射的大文件的处理
• 5.1.2：CMapAwareDocumentFont：如果映射未初始化，则修复 NPE（我宁愿以垃圾字符结束，也不愿在路上抛出意外异常）
• 5.1.3：重构过滤器应用于流的方式，调整解析器使其能够处理多级过滤器
• 5.1.3：图像：允许正确解码 1bpc 位掩码图像
• 5.1.3：图像：添加 jbig2 流以通过
• 5.1.3：图像：处理解码参数中的空引用和间接引用，如果无法解码图像则抛出异常
• 5.2.0：更好的错误消息和更好地处理零大小文件和尝试读取文件末尾。
• 5.2.0：删除了使用内存映射要求文件小于 ~2GB 的限制。
• 5.2.0：避免 RandomAccessFileOrArray 中出现 NullPointerException
• 5.2.0：将 pdfContentStreamProcessor 中的实用方法设为私有，并阐明类的状态性质
• 5.2.0：LocationTextExtractionStrategy：对字符串长度进行边界检查并进行重构以使代码更易于阅读。
• 5.2.0：更好地处理图像中的色彩空间字典。
• 5.2.0：改进对准不当内嵌图片内容的处理。
• 5.2.0：在我们绝对需要之前不要解码内联图像流。
• 5.2.0：避免资源字典的 NullPointerException 未提供。
• 5.3.0：LocationTextExtractionStrategy：旧的比较方法导致 Java 7 中的运行时异常
• 5.3.3：合并 text-rise 参数
• 5.3.3：逐个显示字形信息
• 5.3.3：修正：文本到用户空间的转换被多次应用于 sub-textrenderinfo 对象
• 5.3.3：错误修正：修正基线计算，使其不包括最终字符间距
• 5.3.4：向 LocationTextExtractionStrategy 添加了低级过滤挂钩。
• 5.3.5：修复了 PRTokeniser 中的错误：处理数字位于流末尾的情况。
• 5.3.5：出于性能原因，在 PRTokeniser 中将 StringBuffer 替换为 StringBuilder。
• 5.4.2：向 LocationTextExtractionStrategy 添加了一个 isChunkAtWordBoundary() 方法，以检查是否应在前一个块和当前块之间插入空格字符。
• 5.4.2：在 LocationTextExtractionStrategy 中添加了 getCharSpaceWidth() 方法来获取空格字符的宽度。
• 5.4.2：在 LocationTextExtractionStrategy 中添加了 getText() 方法来获取当前 Chunk 的文本。
• 5.4.2：向 SimpleTextExtractionStrategy 添加了 appendTextChunk(() 方法以公开追加过程，以便子类可以从文本解析操作之外添加文本。
• 5.4.5：为 PDF 解析器添加了 MultiFilteredRenderListener 类。
• 5.4.5：添加了 GlyphRenderListener 和 GlyphTextRenderListener 类，用于处理每个字形而不是处理文本块。
• 5.4.5：在 TextRenderInfo 中添加方法 getMcid()。
• 5.4.5：修复了内容流中有许多内联图像时的资源泄漏问题
• 5.5.0：CMapAwareDocumentFont：如果未定义字体空间宽度，则使用字体的默认宽度。
• 5.5.0：PdfContentReader：在显示空字典时避免异常。

如果您不升级，有些事情您将无法做到。例如，您将无法执行these slides 中描述的操作。

如果您查看the roadmap for iText，您会发现我们将来会在文本提取上投入更多时间。

老实说：使用 5 年前的版本不仅像是重新发明轮子，还像是掉进了过去 5 年中掉入的每一个陷阱。我可以向您保证，购买许可证会更便宜。