Search code examples
pdfpdf-generationitextform-fieldsacrofields

Special characters in PDF form fields and global and fieldbased DR

I have a question regarding a weird form field behaviour.

  1. Two pdf documents, both have textfield(s) using Helvetica as a font
  2. Both are filled with values using the same iText logic (cp. below)

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.

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)

Question(s):

  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
}
Solution

  • 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.

    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.