PDF表单字段以及全局和基于字段的DR中的特殊字符 [英] Special characters in PDF form fields and global and fieldbased DR

问题描述

我对一个奇怪的表单域行为有疑问.

I have a question regarding a weird form field behaviour.

1. 两个pdf文档，都具有使用Helvetica作为字体的文本字段
2. 两者都使用相同的iText逻辑填充值(请参见下文)

两个PDF的字段值(/V)都是正确的，但是字段外观不是正确的.一个Pdf工作正常，其他加扰特殊字符(例如欧元符号€)或德国字符(例如üöäß).我试图定义一种替代字体(如书中所述)，但是没有让€和ß起作用.

The field value (/V) is correct for both PDFs however the field appearance is not. One Pdf is working fine the other scrambles special character like the euro symbol € or German characters like üöäß. I tried to define a substitute font (as described in the book) however never got € and ß to work.

我能找到的唯一区别是/DR字典是在字段级别为非工作PDF定义的(除全局PDF之外).但是，如果我将其删除，则€符号仍然无效.请注意，我在这里不是在谈论亚洲或某些奇异的unicode字符-都是标准helvetica字体的一部分(正如其他PDF所证明的那样)

The only difference I could find is that a /DR dictionary is defined on field level for the non-working PDF (in adition to the global one). But if I remove it, the € sign still doesn't work. Please note, that I am not talking about asian or some exotic unicode characters here - all are part of the standard helvetica font (as the other PDF proves)

问题:

1. 有什么想法如何使无法工作的PDF正确显示字符?
2. 还是PDF某种程度上违反了pdf规范?(它是使用Acrobat创建的，这使得这种可能性不大但并非不可能).
3. 如果您建议替换表单字段字体-如何区分正常和非正常有效的PDF文件，因为我不想为完全有效且有效的文件这么做

1. Any ideas how to get the non working PDF to correctly display the characters?
2. Or does the PDF violates the pdf spec somehow? (It was created using Acrobat which makes that unlikely but not impossible).
3. If you suggest to replace the form field font - how can I differentiate between working and non working PDF files since I don't want to do that for perfectly valid and working files

更新:代码不是问题(我确定是因为这两个代码都是相同的)，但是出于完整性考虑，它是:

Update: The code is not the problem (I am certain of that since its the same code for both) however for the sake of completeness here it is:

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

推荐答案

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

I didn't find any clues in the PDF reference about this, but the font that is used for the field doesn't define an encoding. However: an encoding is defined at the level of the resource dictionary (/DR). If you use that encoding, then the appearance of the field is created correctly. Note that the ISO specification doesn't say anything about the existence of an /Encoding entry at the level of the resource dictionary.

我对iText进行了小幅更新.您可以在修订6693 中检查更改.这样，如果在字体级别未定义编码，则iText现在将检查/DR 词典是否具有编码值.使用此修复程序，您的表单可以正确填写.

I've made a small update to iText. You can check the changes in revision 6693. This way, iText will now check if the /DR dictionary has encoding values in case no encoding is defined at the level of the font. With this fix, your form is filled out correctly.

这篇关于PDF表单字段以及全局和基于字段的DR中的特殊字符的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！