I'm using a pdf with editable form fields. When I click on a field and edit the value manually, it apparently uses different style from the one showing the value in non editing mode. If I change font size in default appearance via PDFBox only visual style of field in editing mode changes but not the style of displayed value.
Field in non editing mode:
field in edit mode:
As seen from the pictures, even the font is different.
Do you have any idea how can I change font size of the displayed value?
Related
When using PDFBox to populate a text field in a form in a PDF, it is possible that the text overflows the text field and is not visible when opening the PDF in a viewer.
Question: Is it possible to use PDFBox to detect how much text within a text field is visible?
At the risk of falling victim to an XY problem, here is the context in which this came up.
I have a PDF which is provided by the Danish government, and the software I am creating needs to be able to fill out this form programmatically. On pages 5 and 6 of this document, there is a large blank area that needs to be filled out. The way the PDF creators designed it, they just made two text fields (named Text57 and Text58), which a person directly filling out the form would manually need to jump between.
The problem is, I need to be able to populate these fields with text, and if the text is too large to fit in the first text field, then it needs to overflow into the second text field. However, I do not seem to have any way of actually detecting when the text overflows in the first text field.
One workaround which could be acceptable, would be if I could modify the document to remove the second text field, and just have the first text field span multiple pages, but while playing around in Acrobat, this does not seem to be possible.
The PDF in question can be found here: https://www.trafikstyrelsen.dk/~/media/Dokumenter/10%20Bolig/Bolig/Private%20lejeboliger/Lejekontrakt/typeformular-a.pdf
Here is a code snippet which populates the problematic field with 100 lines numbered from 1 to 100.
PDDocument document = PDDocument.load(new File("typeformular-a.pdf"));
PDField text57 = document.getDocumentCatalog().getAcroForm().getField("Text57");
text57.setValue(IntStream.range(1, 101).mapToObj(Integer::toString)
.collect(Collectors.joining(System.lineSeparator())));
document.save("typeformular-a.out.pdf");
After the code is run, we can see that the text gets cut off after line 44. Of course I cannot simply count lines in my text, because under normal circumstances the lines in the text will wrap, which would invalidate that approach.
Auxiliary question: Is there any other approach that could solve this original problem of splitting text across multiple pages?
I have a PDF with forms defined in it.
One field in the form is a multi line text field.
The value in the text field is populated by a java program using Apache PDFBox.
The issue is when the value is of around 5 to 6 lines, the text box displays the text automatically. But if it is more than 6 lines, the text box does not display the value. I had to specifically click on the text field to display the text. If I click outside the text box again, the text disappears.
The text field is read only with Multi Line and Scrolling options enabled.
Any ideas what is causing this weird issue?
I have Adobe Acrobat Pro 11, Adobe Acrobat XI and Adobe Reader to view the files. All have the same issue.
It sounds like a typical "appearance" problem. There's no form field appearance in the field widget dictionary so when you click in the field, the raw string data is shown but when you click out there is no appearance to display so you get a blank. You can test this out by toggling the multi-line setting in the field properties in Acrobat so it generates an appearance. If that fixes it, then you the problem is the one I describe.
You can use PDFBox to set the "needs appearances" flag in the file that will tell Adobe viewers to regenerate field appearances when the file is opened but that doesn't work for all PDF viewers. To make the field value visible in all PDF viewers, it's best to generate appearances when you populate the field values.
The Datalogics PDF Java Toolkit can automatically generate appearances based on field values. Full disclosure, I represent Datalogics.
I want to fill out a dual AcroForm/XFA PDF form automatically. I included an XFA dataset packet and all values showed up in Adobe Reader. I set the V= key in AcroForms entries to the new value and all values showed up alternative PDF readers.
However, when I open the PDF with XFA and AcroForm V= entries in Adobe Reader, only the value of the text field that is currently selected is visible:
I cannot find any mention in the PDF specification of a special flag to set when AcroForms and XFA are present. I hypothesized that the order of the XFA and Field keys may be important, but that's not it either.
How can I change my PDF file so that the values are visible in Adobe Reader on startup, and in PDF readers which only support AcroForms and not XFA?
There are 2 questions to be answered:
Why is Adobe Reader only displaying the field value when the field is selected?
How to determine if the AcroForm or the XFA is used?
1. Displayed field values
In some cases Adobe Reader/Acrobat will display a form field differently depending on whether it's selected or not. This is typical for a field that has a defined appearance that is different from how Reader/Acrobat would render the field based on its value (and possibly some appearance settings).
When the field is not selected, the defined appearance will be shown. When the field is selected, a preview of how Reader/Acrobat would render it is shown.
Some background:
A form field consists of a logical part (field name, field value, ...), called the field dictionary, and a visualization part, called the widget annotation. The widget annotation can optionally contain an AP entry, containing the appearance streams that define its visualization. Cf. PDF Specification, 1.7, Table 8.15:
AP - dictionary - An appearance dictionary specifying how the annotation is presented visually on the page.
In the sample PDF there are no AP entries, i.e. blank visualizations. This is what's displayed for all the fields. When selecting a field, you see Reader/Acrobat's preview, based on the field value.
You can verify this by changing a field value manually with Reader/Acrobat. In that case, a new appearance will be generated and saved. That field will now be displayed in the same way, regardless of it being selected or not.
Two options to prevent these "blank" fields in Reader/Acrobat:
Generate appearance streams for all form fields. I have done this for one field (by simply re-setting its value using iText, which automatically generates an appearance stream).
The result:
Internal PDF structure:
Set the NeedAppearances entry in the AcroForm dictionary to true. Cf. PDF Specification, 1.7, Table 8.67:
NeedAppearances - boolean - A flag specifying whether to construct appearance streams and appearance dictionaries for all widget annotations in the document
This will trigger the viewer to generate all the appearances:
2. AcroForm or XFA?
In general, a XFA capable viewer will display the XFA form. A viewer without XFA support will use the AcroForm. You can verify this by setting different values for corresponding AcroForm and XFA fields. This is the result, Chrome's built-in PDF viewer on the left (no XFA support), Acrobat on the right:
Knowing that Reader/Acrobat is using the XFA form, why did we still see the blank fields (cf question 1)?
It seems that, when the values of an XFA field and its corresponding AcroForm field are the same, Reader/Acrobat also uses some information from the AcroForm, a.o. its appearance information. When the XFA value is different from the AcroForm value, the AcroForm field seems to be ignored completely.
TL;DR Set NeedAppearances to true to solve blank fields. XFA-incapable viewers will fall back to AcroForm automatically.
(My tests are based on Adobe Acrobat X.)
Is there a way to scale a report to fit in the printable area? Like Adobe Reader. My reports are in A4 size, but they're to close too the page borders. I bought a new printer, and the printable area is smaller than the old one, and there are some cuts in the report.
I didn't change the paper size or whatever, just the printer.
Here is an image of what's happening:
A few ideas:
By default, Crystal tends to have the Use Default Margins option selected - the default margins are not always set to the maximum printable area of the page. The answer could be as simple as unchecking the Use Default Margins option in the Page Setup dialog (from the File > Page Setup... menu) and adjusting the margins to match the previous printer's default settings.
Alternatively, some printer drivers include a scale to fit option - if this is available, it should be possible to set it within the Print Setup dialog (from the File > Printer Setup... menu option) by clicking the Properties button immediately beneath the printer name and specifying the appropriate option within the printer driver's properties.
A possible workaround (if neither of the previous ideas works) would be to export the printer output to PDF (with the old printer set as the report printer), and then print the exported PDF document to the new printer from the PDF viewer.
I'm trying to build a web app to programmatically fill out a PDF form. I am going to configure my form first in Adobe Acrobat, then write a Java app with iText to fill out all the form fields via user input from the web. The base form I need to fill out comes from the US government. They created form fields with extremely large kerning (character spacing) values I need to change. However, there appears to be no way to modify this value in the Acrobat UI.
Does anyone know how to manipulate character spacing on form fields in Acrobat 8.0 for Windows? I could try to use iText to programmatically manipulate the kerning of the original document, but this would be much more tedious.
I believe I figured this out: kerning is called "combing" in acrobat, and each of the form fields have been "combed". The strange thing is this option isn't checked when I view the properties of the form field, but "combing" is the behaviour I was attempting to replicate.