我正在尝试使用iText 4.2.1制作阿拉伯语pdf文档。这些文档基于Word xml格式提供的模板。我就在那里,但遇到了障碍。
源文档使用简化阿拉伯语字体并显示正常,因此我在PDF中使用了相同的文档。在大多数情况下,一切都很好,但偶尔它会下降"一个角色。
我已经通过iText源跟踪,可以看到它从0x06xx基本代码转换为0xFExx呈现代码的位置,具体取决于整形规则。一旦它转换为演示代码,它就会在写入文档输出流之前依次从字体文件中查找每个字符的度量。在这里,它有时无法在字体中找到所需的表示代码,因此只需省略所有字符。
例如,字符0x0645使用charMap表中的这一行转换为0xFEE2
{0x0645, 0xFEE1, 0xFEE2, 0xFEE3, 0xFEE4}, /* MEEM */
...而0xFEE2不是简体阿拉伯字体。
鉴于文档在Word中使用相同的字体显示正常,iText是否应该恢复使用基本代码0x6xx进行演示?如果是这样,这是在图书馆的商业版本中得到解决(如果有必要,我很乐意为此付费)。
或者,这是其他图书馆必须解决的字体问题
是否还有其他人遇到此问题或类似情况?若然,您采取了哪些措施来解决此问题?
答案 0 :(得分:2)
阿拉伯语在0x6xx范围内有一个逻辑文本表示,在另外两个范围内有一个视觉表示: FB50 - FDFF阿拉伯语演讲表格 - A. FE70 - FEFF阿拉伯语演讲表格-B
必须使用演示范围,因为每个角色可能有四种表示形式,具体取决于单词位置:初始,中间,最终和隔离。其他结扎也是可能的。
不使用强大的旧iText版本,如果字符不在字体中,则无法表示。如果字体缺少字符,Word将使用其他字体,或者它可能使用替代字符。尝试使用Arial来确保连字是正确的。
答案 1 :(得分:0)
我们最近遇到了同样的情况,我们正在介绍我们为此问题所做的工作:
当我们使用PDFBox提取文本时,我们收到了Presentation Form A和B系列Unicode中的字符。有趣的是 - 因为我们无法读取阿拉伯语 - 当我们在谷歌翻译中复制和粘贴文本时 - 我们收到了相同的输出,但是当我们通过计算差异来做差异时 - 我们收到了两个字符串之间没有任何共同点。 [直到那个时间点 - 我们没有意识到正常的unicode阿拉伯语,阿拉伯语的表现形式 - 这也是unicode等的一部分]
我们有从PDF中提取原始字符集的业务要求。这很具挑战性 - 演示表格A& B每个字符有大约4种形式[取决于它在单词中的位置]。
我们积极浏览互联网 - 如果有任何图书馆 - 可以建立两者之间的关系。
值得庆幸的是 - Unicode有Replacement Characterset - 它定义了我们如何从Presentation Form A& amp; B字符[Character Fall Back Substitutions] - 设置为普通Unicode字符集。
http://www.unicode.org/cldr/charts/29/supplemental/character_fallback_substitutions.html
使用上述数据源 - 我们能够将阿拉伯语演示文稿中的591/611字符的正常阿拉伯字符集定义为unicode集和阿拉伯语演示表单B unicode字符集中的139/143字符。
Adobe - 也有Adobe字形列表规范 - [可在github上获得] - 它也定义了字形和它们的unicode之间的关系 - 但对于阿拉伯语来说是不完整的,因为它定义了257个字符 - 这也主要落在阿拉伯语表格A中系列。
此外 - 在我们的案例中 - 没有遗漏字符。这些字符仅从我们关注的普通阿拉伯语Unicode翻译成演示文稿表格。
在我们原来的MS Word文档中 - 有表格 - 里面有内容。在翻译的阿拉伯语中 - 我们收到了FFFD unicode字符[questionmark,表示有些字符在unicode发生变化时无法翻译。] IF删除所有这些FFFD字符 - 剩余文本 - 虽然转换为Presentation表单unicode集 - 与原始版本具有相同的含义。
我们确实花了大量时间在转换成PDF时解决这个unicodes更改问题,并希望我们的经验也能帮助其他人。