Develop Reference

PDFBox Embeded fonts not working when filling form

I fill forms with field.setValue. However even though PDF document has embedded fonts in it, I am getting error "is not available in this font's encoding: WinAnsiEncoding" no matter which type of font it is. Note that this is happening for chinese or russian characters.

Your PDF documents may have embedded fonts but they apparently have been embedded with an Encoding value WinAnsiEncoding.
WinAnsiEncoding contains essentially the Latin-15 characters, so it is intended for “Western European” languages (see the Wikipedia article on this) and in particular neither for Cyrillic nor for CJK languages.
If you want to fill chinese or russian characters into form fields using PDFBox, therefore, you have to
either embed a font into your PDF using an appropriate encoding beforehand
or replace the embedded font with PDFBox right before setting the form field value, see for example this answer.

itext5 sign image over context

When I sign a document and I use an image in the signature appearance, I get this result:
However, I want the result to be like this:
This is my code:
PdfSignatureAppearance appearance = stamper.getSignatureAppearance();
appearance.setReason(info.getReason());
appearance.setLocation(info.getLocation());
appearance.setVisibleSignature(t.getRectangle(), 1, "SIGN");
appearance.setSignatureGraphic(image);
appearance.setCertificationLevel(PdfSignatureAppearance.NOT_CERTIFIED);
appearance.setRenderingMode(PdfSignatureAppearance.RenderingMode.GRAPHIC);
MakeSignature.signDetached(appearance, digest, signature,chain, null, null, null, 0, MakeSignature.CryptoStandard.CADES);

The visual representation of a digital signature in a PDF document is a widget annotation. A widget annotation is a specific type of annotation.
In PDF, you have the actual content of a page. This content is stored in a content stream. A page is defined in a page dictionary. There's a /Contents entry in this page dictionary that refers to one of more content streams. Together these content streams contain the syntax that describes the content of a page.
Annotations are not part of any of those streams. Annotations are referred to from the page dictionary using the /Annots entry. In your case, there is an /Annots entry that refers to a widget annotation with the appearance of your signature.
All annotations are rendered on top of the actual page content.
To make a long story short: you have a PDF with some page content and the appearance of an annotation is added on top of that page content. This is normal. This is as described in ISO-32000-1. You are now asking for a PDF viewer to render annotations under the page content. This is not possible according to the PDF specification.
The short answer to your question is: you are asking something that can't be done. The closest you'll get to a solution is to make the image transparent (but that's another question).

While Bruno's answer is correct - there is no way to make the signature annotation appearance to be beneath the content -, in some cases you can make it appear to be.
Blend mode use
Bruno already mentioned that one approach might be to make the image transparent. Regular (alpha channel style) transparency has one major disadvantage, though: the original content or the image (probably both) will appear somewhat pale. But there is a related technique in PDF for puting foreground and backdrop together in a special way: blend modes.
In particular if your pdf content is mostly black and white, using the blend mode Darken or Multiply will create a result looking like the desired image.
Signature graphic in content
If your pdf has not been signed yet, you can actually add the signature image to the page background itself, e.g. using the UnderContent of the PdfStamper. (If the page has an opaque background, e.g. due to white filled rectangle as background, this will become a bit more difficult but still manageable.)
Page content in signature appearance
Alternatively you can draw a copy of the page content over the image in the signature annotation appearance. This also works for previously signed PDFs but is also sensitive to opaque page contents.

PDF/A's Checkbox - iText 2.1.7

I need to print a PDF/A document with my Java App, which implements iText 2.1.7. When I use a PDF Templates, my app works fine and print the checkbox checked if they satisfy the conditions.
But, when I use PDF/A Templates, my app doesn't fill these checkbox, but they receive the values correctly.
Can anyone help me? I dont know if this problem is in the template or in the code.

Can you describe in more detail what you are doing?
thesis I:
If you have a (non PDF/A) PDF with form fields and then you programmatically change a checkbox value with iText then the change is visible in the PDF (e.g. you can see it in adobe reader and on printed paper)
Correct?
thesis II:
If you have a PDF/A compliant PDF and change the value of a checkbox then the change is not visible in the PDF (neither in adobe reader nor on printed paper)
Correct?
In the PDF format you need to differentiate between the appearance of a field and the (data) value of a field. Normally PDF/A documents are made for long term archiving and not to change values. If you still do that you need to ensure that you also update the appearance of a form field.
Try to update the appearance of the field you change (after you set the new value). You can do that with the following method:
AcroField fields;
boolean success = fields.regenerateField(String yourCheckboxFieldName);

How to check a checkbox in PDF file with the same variable name with iText and Java

I have been using iText library for Java to fill automatically a PDF Document. The first thing I do is map every field. Once I get every field mapped, I save the variables name into Strings to be easy to be accessible.
So far, so good. The problem is that I have a group of 6 checkboxes with the same variable name. For exemple, they are named topmostSubform[0].Page2[0].p2_cb01[0].
With some tests I could figure out that if I check the first checkbox so the topmostSubform[0].Page2[0].p2_cb01[0] = 1
If I check the second one (that unchecks the first automatically) so topmostSubform[0].Page2[0].p2_cb01[0] = 2
Then topmostSubform[0].Page2[0].p2_cb01[0] = 3 successively until it gets the the number 6 that is the last one.
I am using form.setField("topmostSubform[0].Page2[0].p2_cb01[0]", "1");to fill up the fields. When I fill with the value 1 the first checkbox gets checked, but when I fill with the number 2 that should check the second checkbox it does not work. It does not matter if I choose 2, 3, 4, 5 or 6 it just does not work, the checkboxes stay empty and I can`t check them.
Here a piece of the code:
String _5_1 = "topmostSubform[0].Page2[0].p2_cb01[0]";
AcroFields form = stamper.getAcroFields();
form.setField(_5_1, "3");
Please, I need suggestions.

Allow me to quote from ISO-32000-1 section 12.7.3.2 "Field names":
It is possible for different field dictionaries to have the same fully
qualified field name if they are descendants of a common ancestor with
that name and have no partial field names (T entries) of their own.
Such field dictionaries are different representations of the same
underlying field; they should differ only in properties that specify
their visual appearance. In particular, field dictionaries with the
same fully qualified field name shall have the same field type (FT),
value (V), and default value (DV).
If we apply this to your question: it is possible for different field dictionaries to have the same name topmostSubform[0].Page2[0].p2_cb01[0]. Such field dictionaries are different representations of the same field and they shall have the same value.
There are two options:
If you have a PDF with field dictionaries with name (topmostSubform[0].Page2[0].p2_cb01[0]) that have different values, then you don't have a valid PDF file: it is in violation with ISO-32000-1, which is the official PDF specification.
Maybe you think that you have check boxes with the same field name and different values, but maybe those check boxes are in reality a radio field with different radio buttons. Maybe you are not using the correct values. Maybe something else is at play. For a SO reader to be able to help you, he'd need to see the PDF file.
If option 1 applies, abandon all hope: you have a bad PDF. Fix it or throw it away. If option 2 applies, please share the PDF.
Update after inspecting the PDF file:
Option 2 applies. You have a hybrid form, which means that the form is described twice inside the PDF, once using AcroForm technology and once using XFA. Please start by reading my answer to the following question: PDFTK and removing the XFA format
When you open the PDF in Adobe Reader, you will notice that the fields act as if they are radio buttons. When you click one, it is selected, but when you click another, it is selected, but the first one is no longer selected.
What you see, is the form as described in XFA, and there are some important differences between the XFA form and the AcroForm description. This isn't an error. It's inherent to hybrid forms.
When you fill out the form using:
form.setField("topmostSubform[0].Page2[0].p2_cb01[0]", "1");
iText fills out the AcroForm correctly, but it fails at filling out the XFA form because iText makes an educated guess (not an accurate guess) as to where the corresponding value should be set in the XFA stream (which is actually expressed in XML). For more details: this is explained in chapter 8 of iText in Action - Second Edition.
What I usually do in such cases is exactly what the person who asked if he could safely throw away the XFA part does: I remove the XFA part:
AcroFields form = stamper.getAcroFields();
form.removeXfa();
This simplifies things dramatically, but it doesn't solve your problem yet. To solve your problem, we need to look inside the PDF:
As you can see in the screen shot (taken from iText RUPS), there are two different descriptions for the form: you have a /Fields array (the AcroForm description) and you have an /XFA part that consists of different streams that, if you join them, form a large XML file.
We also see that where you think there's a single field topmostSubform[0].Page2[0].p2_cb01[0], there are in reality 6 fields:
topmostSubform[0].Page2[0].p2_cb01[0]
topmostSubform[0].Page2[0].p2_cb01[1]
topmostSubform[0].Page2[0].p2_cb01[2]
topmostSubform[0].Page2[0].p2_cb01[3]
topmostSubform[0].Page2[0].p2_cb01[4]
topmostSubform[0].Page2[0].p2_cb01[5]
Now let's take a look inside those fields.
This is field topmostSubform[0].Page2[0].p2_cb01[0]:
This is field topmostSubform[0].Page2[0].p2_cb01[0]:
These are AcroForm check boxes, but there an instruction meant for humans that says: select only one. This instruction can be understood by humans only, not by machines or software.
My first attempt at writing the FillHybridForm example failed because I made a similar error to yours. I didn't look closely enough at the different appearance states. I thought that the On value of topmostSubform[0].Page2[0].p2_cb01[0] was 0, of topmostSubform[0].Page2[0].p2_cb01[1] was 1, and so on. It wasn't... The On value of topmostSubform[0].Page2[0].p2_cb01[0] was 1, of topmostSubform[0].Page2[0].p2_cb01[1] was 2, and so on.
This is how you can fill out all the check boxes:
public void manipulatePdf(String src, String dest) throws DocumentException, IOException {
PdfReader reader = new PdfReader(src);
PdfStamper stamper = new PdfStamper(reader, new FileOutputStream(dest));
AcroFields form = stamper.getAcroFields();
form.removeXfa();
form.setField("topmostSubform[0].Page2[0].p2_cb01[0]", "1");
form.setField("topmostSubform[0].Page2[0].p2_cb01[1]", "2");
form.setField("topmostSubform[0].Page2[0].p2_cb01[2]", "3");
form.setField("topmostSubform[0].Page2[0].p2_cb01[3]", "4");
form.setField("topmostSubform[0].Page2[0].p2_cb01[4]", "5");
form.setField("topmostSubform[0].Page2[0].p2_cb01[5]", "6");
stamper.close();
reader.close();
}
Now all the check boxes are checked. See f8966_filled.pdf:
Of course: being human, we know that we shouldn't do this, because we should treat the fields as if they were radio buttons, but there is no technical reason in the AcroForm description why we couldn't. The logic that prevents us to do so, is only present in the XFA description.
This solves your problem if it is acceptable to throw away the XFA part. It will also solve your problem if it's OK to flatten the form in which case you should add:
stamper.setFormFlattening(true);
If you the above options aren't acceptable, you shouldn't throw away the XFA part, but fill out the AcroForm part as described above and use iText to extract the XML dataset (see datasets in the first screen shot), update it the way the US government expect you to update it, and use iText to put the updates dataset back in the datasets object.
Phew... This is one of the longest answers I ever wrote on StackOverflow.

Overlapping characters in text field iText PDF

I have PDF with text field which contains some characters. But the language specific characters are overlapping.
When it gains focus, text changes and displays correctly. When lost focus, displays incorrectly.
When text is edited displays also correctly.
File test_extended_filled.pdf see bellow
How I created PDF:
Created odg template in OpenOffice Draw 4.0.1 -> test.odg
Exported as PDF -> test.pdf
Edited test.pdf with Adobe Acrobat X Pro 10.0.0 and resaved with extended functions (needed to save on local PC) -> test_extended.pdf
Filled form by java (pdfstamper) -> test_extended_filled.pdf
Bonus: when i change font by pdfstamper in java it looks like changes are applied only on focused text too. -> test_extended_filled_font_size.pdf
Note: When I fill test.pdf from 2. it's displayed correctly -> text_filled.pdf
Attached files (go to download section):
https://rapidshare.com/share/ACC0D81E9235A6DA2CC2353BD21A4C37
After I added
stamper.getAcroFields().addSubstitutionFont
it's better, but some characters still overlap. -> test_extended_filled_font_size_with_substitution_font.pdf
http://rapidshare.com/share/0EE3238F37E9115C36A7A74706B09826
Any ideas?

Please take a look at the FillFormSpecialChars example and the resulting PDF.
Open Office doesn't really create nice forms. As mkl already indicates, the NeedAppearances flag can cause problems, the border of the fields is drawn onto the page content instead of being part of the widget annotation, etc...
In your case, you've defined a font that isn't optimal for special characters. Using a substitution font isn't ideal, because you can clearly see that drawing the glyphs isn't that much of a problem. The problem is that the metrics are all wrong. It's as if the special characters have an advance of 0 glyph units. In this case, you should change the font using the setFieldProperty() method.