1

我有一个关于奇怪的表单字段行为的问题。

  1. 两个 pdf 文档，都有使用 Helvetica 作为字体的文本字段
  2. 两者都使用相同的 iText 逻辑填充值（cp. below）

两个 PDF 的字段值 (/V) 都是正确的，但字段外观不正确。一个 Pdf 工作正常，另一个打乱特殊字符，如欧元符号 € 或德语字符，如 üöäß。我试图定义一种替代字体（如书中所述），但从未让 € 和 ß 起作用。

我能找到的唯一区别是 /DR 字典是在字段级别为非工作 PDF 定义的（除了全局字典）。但是如果我删除它，€ 符号仍然不起作用。请注意，我在这里不是在谈论亚洲或一些异国情调的 unicode 字符——它们都是标准 helvetica 字体的一部分（正如其他 PDF 所证明的那样）

问题）：

  1. 任何想法如何让非工作 PDF 正确显示字符？
  2. 还是 PDF 以某种方式违反了 pdf 规范？（它是使用 Acrobat 创建的，这使得这不太可能但并非不可能）。
  3. 如果您建议替换表单字段字体- 我如何区分工作和非工作 PDF 文件，因为我不想为完全有效和工作的文件这样做

更新：代码不是问题（我可以肯定，因为两者的代码相同）但是为了完整起见，这里是：

AcroFields acroFields = stamper.getAcroFields();
try {
    boolean successful = acroFields.setField("Mitarbeiter", "öäü߀@");
    if (!successful) {
        //throw some exception
    }
}
catch (DocumentException de) {
    //some exceptionhandling
}
4

1 回答 1

1

我在 PDF 参考中没有找到任何关于此的线索，但用于该字段的字体没有定义编码。但是：编码是在资源字典 ( /DR) 级别定义的。如果您使用该编码，则正确创建字段的外观。请注意，ISO 规范没有说明/Encoding资源字典级别是否存在条目。

我对 iText 做了一个小更新。您可以检查修订版 6693中的更改。这样，iText 现在将检查/DR字典是否具有编码值，以防在字体级别未定义编码。通过此修复，您的表单已正确填写。

于 2015-01-13T16:43:49.693 回答