PDF 表单域中的特殊字符以及全局和基于域的 DR

Question

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

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

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

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

问题：

有什么想法可以让无法正常工作的 PDF 正确显示字符吗？
或者 PDF 是否以某种方式违反了 pdf 规范？（它是使用 Acrobat 创建的，这不太可能但并非不可能）。
如果您建议替换 form field font - 我如何区分工作和非工作 PDF 文件，因为我不想对完全有效和工作的文件这样做

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

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

Answer 1

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

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

PDF 表单域中的特殊字符以及全局和基于域的 DR

Special characters in PDF form fields and global and fieldbased DR

pdf

pdf-generation

itext

form-fields

acrofields