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

Question

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

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

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

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

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

提前致谢！

Answer 1

我是iText Software的首席技术官，所以就像Michaël在评论部分已经有answered一样，我同时也是最权威的来源以及有偏见的来源。

有一个非常简单的比较图表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的Getters
• 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：对线段实施的调整;优化Bruno对文本提取所做的更改;例如：Mark ContentInfo类的介绍。
• 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 cmaps。
• 5.0.6：处理略有格式的嵌入图像
• 5.0.6：CMapAwareDocumentFont：某些PDF的diff映射大于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：images：处理解码参数中的空值和间接引用，如果无法解码图像则抛出异常
• 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：修正：文本到用户空间转换被多次应用于子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年中遇到的每一个陷阱。我可以向您保证，购买许可证会更便宜。