【发布时间】：2012-11-10 23:59:39
【问题描述】：
lowagie 和 iText 有什么区别？这只是版本差异还是库的升级。推荐使用哪一种？
【问题讨论】：
【发布时间】：2012-11-10 23:59:39
【问题描述】：
我是Lowagie，你说的那个lowagie。我是 iText 的原作者，也是“iText in Action”书籍和关于 iText 历史的“企业家”书籍的作者。
当人们在 PDF 的上下文中谈论 lowagie 时，他们通常会谈论带有包名 (Java) 或命名空间 (C#) 的库，例如 com.lowagie.text (Java)。这些是 iText 的旧版本（版本 0、1 或 2）。最后一个旧版本是 2009 年 7 月或更早的 iText 2.1.7。
有一个 iTextSharp 3 和 4 (C#)，但从来没有一个官方的 iText 3 或 4 版本 (Java)。有分叉号称是基于 iText 4 的，因为数字 4 是临时用在开源仓库中，为 iText 5 的发布做准备。有了 iText 5，Java 和 C# 版本的发布数字终于有了同步。
当人们谈论 iText 时，他们通常会在更新日志中找到更新版本的 iText：http://itextpdf.com/changelog
iText 5 版本有以下重大变化：
- iText.jar 是使用 Java 5（而不是 JDK 1.4）编译的。
- F/OSS 许可证已从 MPL/LGPL 升级到 AGPL。
- 软件包名称已从
com.lowagie更改为com.itextpdf。 - 工具箱和 RTF 支持已被删除：它们现在位于 SourceForge 的单独项目中。
从来没有正式的 iText 6 版本； iText 6 仅存在于 iText Group 内部，为 iText 7 做准备。
iText 7 版本是对库的完全重写。想要从 iText 7 之前的版本迁移的人将不得不重写他们的代码，因为 iText 7 与之前的版本不兼容。
从头开始创建新版本的原因有很多：
- 重写字体层对于支持连字和书写系统（如梵文（印地语）、Gurmukhi（旁遮普语））以及支持许多其他印度语言（如卡纳达语、泰卢固语、马拉地语、乌尔都语）是必要的由于字体在这些版本中的实现方式，使用旧版本的语言生成 PDF。
- 重写库为解决 API 中的大量歧义和不一致提供了机会。从 iText 7 开始，该库不再是一个单一的 jar，而是一组 jar，您可以根据需要的功能从中挑选。
- iText 5（及更早版本）的设计始于 2000 年 2 月。它早于 2012 年发布的 PDF/UA 标准，并且没有考虑可访问性。为在 iText 5 中支持 PDF/UA 付出了巨大努力，但我们不得不承认，可访问性功能被固定在不是为此目的而创建的现有库上。 iText 7 的设计以生成可访问的 PDF 作为先决条件。作为副作用，在 iText 7 中 HTML 到 PDF 的转换比在 iText 5 中要好得多。
- iText 7 也是唯一支持最新 PDF 2.0 标准的版本。以前版本的 iText 只能生成 PDF 1.7 或更早版本的文件。
- 另一个重要的发展标准涉及数字签名。请注意，您当然不应该使用 iText 2（或更早版本，或克隆版本）来创建数字签名，因为“lowagie”可以追溯到 2009 年，而从那个时候开始的所有数字签名标准都已经过时了。
如需更全面地了解 iText 的历史，以及发生变化的方式和原因，请访问Entreprenerd 网站。
答案于 2021 年 7 月 21 日更新：自 2020 年 3 月起，我不再隶属于任何 iText 公司。
【讨论】：
-
您的回答令人困惑。您应该马上声明，包名和产品名是不同的。不是每个人都在寻找 iText。我只是想知道我正在使用的这个类中导入的到底是什么包，并用“Lowagie”搜索了包名。您只需要说：旧版本的 iText 具有此包名称结构。先生，汤姆的反应要好得多。
-
@BrunoLowagie - Gosling 和 Java 之间的关联并不相同，因为 JDK 中的包名从来都不是 java.gosling.*
-
@BrunoLowagie 人们不理解的原因是因为我们中的一些人以前从未使用过 iText，并且不是我们项目的原始程序员。我正在开发一个使用 iText 的应用程序，但我不知道这一点，因为包目录中根本不包含 iText - 只是对您姓氏的引用。您可能应该明确地说该包指的是 iText 的开发人员 - IE，您。 ;)
-
@BrunoLowagie - 停止使用它并不容易.. 我们使用 jasper 报告，这取决于 IText 的低版本，我们不能删除 jasper，也不能轻易替换它.. 你知道事情不会在公司中轻松改变这一点。
-
@BrunoLowagie 与其他库存在一些依赖冲突，我想知道哪个版本的 iText 引入了某些方法等。
其实没有区别：在 iText 2.1.0 中。创建一个 PDF，转到属性并查看“lowagie.com 的 iText 2.1.0”））在 lib 的演变中似乎发生的事情是 java 包名称中的“lowagie”被替换为“itextpdf”。
这是我的第一个答案。布鲁诺不喜欢它））。好的——当然，java lib 的生命周期发生了很多变化。我的意思是“lowagie”与 iText 是同一个库（尽管在早期版本中）。我认为 Bruno 对重新命名 lib 非常感兴趣，并且不希望它被称为 lowagie。很好——但无需刻意——lowagie 是之前版本中的 iText。
Axe，让我再试一次……有一些东西，比如开源品牌/企业，他们有一个网站，它以创建者“lowagie.com”的名字命名。它是一个java lib。当我们使用它时，我们看到包装结构反映了这种品牌选择“lowagie”，如下所示：
import com.lowagie.text.Document;
import com.lowagie.text.DocumentException;
import com.lowagie.text.Element;
import com.lowagie.text.Font;
import com.lowagie.text.Image;
import com.lowagie.text.PageSize;
import com.lowagie.text.Paragraph;
import com.lowagie.text.pdf.PdfContentByte;
import com.lowagie.text.pdf.PdfImportedPage;
import com.lowagie.text.pdf.PdfReader;
import com.lowagie.text.pdf.PdfWriter;
import com.lowagie.text.pdf.PdfStamper;
所以，我坚持我的回答，并断言 iText 使用了两个品牌：iText 和 lowagie.com。但现在很明显，有一个摆脱“lowagie”并坚持使用 iText 的举措。
【讨论】：
-
我对这条评论的欣赏远胜于 Lowagie 先生的评论。感谢您提供 5.0.0 版本的变更日志说明，说明包名称已更改。现在我知道它是同一种产品，只是我可以决定购买的更新/更好的版本。
-
@BrunoLowagie - 更改 Toms 的答案似乎扩展了 stackoverflow 编辑的规则。虽然您最初对有关 lowagie 是姓氏的问题给出了“准确”的答案，但它最无济于事。在我找到这篇文章之前，我将 lowagie 与 iText 库相关联，但感谢您纠正这种误解。我想说您提供的当前答案是明确且有用的。在您的辩护中，问题应该更准确地写成“iText 包 com.lowagie 和 com.itext 中的库有什么区别”。
-
正确。我，作为@Revoman，我猜也像提出这个问题的人一样，并且（我猜）像许多其他人一样，我们（有）品牌混乱。问题类似于“嘿，我看到了这个“lowagie 品牌，我看到了这个 itext 品牌，它们是一样的吗？”答案是肯定的！！！它是同一个 pdf 操作/创建库）） )) 简单 )))。但现在 itext 选择从包名称/品牌中删除“lowagie”。简单的答案。
-
哦——这里有一个很大的假设需要明确说明——在 java 中，包名称至少在历史上反映了品牌决定。换句话说，我们通过在 java 命名空间中看到的名称“调用”java app/lib。我能想到的唯一例外是源锻造托管应用程序。但即便如此，人们也会迅速声明他们的品牌/www 域，如 net.sf.jasperreports.engine.export.AbstractPdfTextRenderer
-
在 maven pom.xml 中有一个名为 groupid 的元素，它是“创建项目的组织或组的唯一标识符”。从repo1.maven.org/maven2/itext/itext/1.3.1/itext-1.3.1.pom 可以看出，该组织以前是 com.lowagie，现在是 itext。
到目前为止，还有OpenPDF 使用来自 com.lowagie 的类，因此您可能还需要考虑您的项目的某些依赖项可能依赖于 OpenPDF。
【讨论】：