Default Appearance /DA dictioanry entry (Textbox)

[ognjen.stefanovic]

Hello everyone,

We recently purchased a license and integrated this library into our workflow. However, we’ve encountered a slight issue.

Our client has a program with a pre-existing workflow that replaces TextBox fields in PDFs with different values, fonts, etc., based on their specific needs. The font replacement relies on the fact that each TextBox has a /DA (default appearance) entry in its field dictionary.
Something like this:

Code: Select all

/Helvetica 21 Tf 0.4470588235294118 0.3215686274509804 0.6745098039215687 rg

is replaced with

Code: Select all

/Ubuntu-Bold 21 Tf 0.4470588235294118 0.3215686274509804 0.6745098039215687 rg

.
This second part changes from client to client.

The issue we’re facing is that Spire.PDF doesn’t seem to attach the /DA property directly to the TextBox. Instead, it creates an Annotation where the /DA is placed and then connects that Annotation to the field using a /Kids entry.

Is there any way to achieve the /DA property being attached directly to the TextBox instead of the current implementation? Any guidance or suggestions would be greatly appreciated!

Thank you in advance for your help!

[Nina.Tang]

Hi,

Thanks for your inquiry.
After investigating your issue, I have found that updating the content of the textbox field or modifying its font will not result in a change in the position of the/DA entry. This entry always remains consistent with the location defined in my original PDF. The following is the code I used.

Code: Select all

 PdfDocument doc = new PdfDocument();
 doc.LoadFromFile("test.pdf");

 // Get the form widget from the loaded PDF document
 PdfFormWidget formWidget = doc.Form as PdfFormWidget;

 // Iterate through each field in the form
 for (int i = 0; i < formWidget.FieldsWidget.List.Count; i++)
 {
     // Get the current field
     PdfField field = formWidget.FieldsWidget.List[i] as PdfField;

     // Check if the field is a TextBox field
     if (field is PdfTextBoxFieldWidget)
     {
         // Convert the field to a TextBox field
         PdfTextBoxFieldWidget textBoxField = field as PdfTextBoxFieldWidget;

         // Update font
         textBoxField.Font = new PdfTrueTypeFont(new Font("Times New Roman", 12,FontStyle.Regular));
     }
 }
 doc.SaveToFile("updatefont.pdf", FileFormat.PDF);


Could you please provide more detailed explanation of your issue to help up understand your issue better? For example, how do you handle PDF file? In addition, if you can provide relevant input and output PDF files, as well as your test code, it will help us locate and solve problems more efficiently.

Sincerely,
Nina
E-iceblue support team

[ognjen.stefanovic]

Hi.

Maybe I can explain in more detail the problem.
We are using Chromium to generate PDF, and after that, Spire.PDF to introduce Textbox fields, since Chromium does not have this functionality.
In the original PDF, there are no fields, and we add them with this library. This newly generated PDF is then used by some external software, which relies on /DA entry on Textboxes.

The issue is, PDF generated with Spire.PDF does not have /DA entry on the Textbox, but rather in the related /Kids entry.
We checked the PDF specification and found this:
Section "8.6.2 -> Variable Text" defines the "DA" entry as Required; inheritable. So, either the form field's dictionary contains the "DA" entry or one of its parents does.

Also, we checked the PDF implementations for OpenPDF and PDFBox. Both these implementations look for the "DA" entry by checking if it is directly in the form field's dictionary or by traversing the parents. So this is in accordance with the specification. None of them look into the "Kids" entry to check if the "DA" entry is there.

I hope this clarrifies the issue that we are having.
Thank you.

[Nina.Tang]

Hi,

Thanks for your detailed explaination.
Our Spire.PDF provides the following code to add a textbox field.

Code: Select all

PdfDocument doc = new PdfDocument();
// Create a new page
PdfPageBase page = doc.Pages.Add();

// Create a PdfTextBoxField
PdfTextBoxField textbox = new PdfTextBoxField(page, "TextBox");
textbox.Bounds = new RectangleF(20, 50, 100, 15);
textbox.BorderWidth = 0.75f;
textbox.BorderStyle = PdfBorderStyle.Solid;

// Add the text box field to the form fields collection of the PDF document
doc.Form.Fields.Add(textbox);

doc.SaveToFile("spireout.pdf", Spire.Pdf.FileFormat.PDF);


However, when I used a specific tool to check the spireout.pdf, I found that it has the/DA entry on the textbox, instead of the /Kids entry. Based on my understanding, PDFBox provides the method (textBox.getDefaultAppearance()) to read /DA entries in text boxes. I can successfully obtain the/DA entry from the spireout.pdf using the PDFBox, and the result is "/Helv 12 Tf 0 g".

Therefore, I would like to further understand: How did you determine that the text box created by our product does not have a /DA entry? What analysis or tool is the basis for this confirmation? Here I also provide the spireout.pdf I generated for your better reference, please provide further evidence to help us better understand your question.

Sincerely,
Nina
E-iceblue support team

[ognjen.stefanovic]

Thank you for the example and explanation.
What I did now is checked the PDF that you provided in the attachments with the same tool as before and found the same thing:
TextBox has /Kids entry with /DA inside, and not on the parent.

The tool that we used is an online-based PDF Inspector tool, called PDFCrowd. You can find it at pdfcrowd.com/inspect-pdf.

Our client is using different external software for integration, and when they try to process our report (generated with Spire.PDF) they are facing the same issue, missing /DA entry on the parent.

Maybe you can give this tool a go and check the results.

Thank you again for the time and effort.

Best regards,
Ognjen

[Nina.Tang]

Hi Ognjen,

The information you provided is very detailed, and I fully understand your issue now.
I directly created a Textbox field using Adobe and compared it with the textbox generated by Spire.PDF using your tool for verification. I did notice that the/DA entry of the toolbox created by Spire.PDF exists under the annotation. Please refer to the comparison screenshot. I have handed over this issue to the dev team for further investigation, and the issue number is SPIREPDF-7426. If there is any update, I will inform you promptly.

Sincerely,
Nina
E-iceblue support team

[Nina.Tang]

Hi Ognjen,

Glad to inform you that the reported bug SPIREPDF-7426 has been resolved and the new version (Spire.PDF Pack(Hot Fix) Version:11.4.10) is available. Please download it from the following link.
Websit download link: https://www.e-iceblue.com/Download/download-pdf-for-net-now.html
Nuget download link：https://www.nuget.org/packages/Spire.PDF/11.4.10
https://www.nuget.org/packages/Spire.PDFfor.NETStandard/11.4.10

Sincerely,
Nina
E-iceblue support team

[ognjen.stefanovic]

Hi Nina,

Thank you for the information. Unfortunately, we have checked, and even in the new version 11.4.10, we experience the same behaviour.
The /DA entry is found on the /Kids section, and not directly on the Textbox.

Best regards,
Ognjen

[Nina.Tang]

Dear Ognjen,

Thanks for your feedback.
After carefully comparing the text boxes generated by the old version, Adobe native creation, and the latest version 11.4.10 using the PDFCrowd tool, we found that the new version 11.4.10 has optimized the hierarchical structure of /DA entries and now maintains complete consistency with Adobe native created text boxes. For your convenience, I have compiled the detailed comparison results in the attachment. I'm really not sure what structure you need on your end. Can you provide further explanation based on the screenshot in my attachment?

Sincerely,
Nina
E-iceblue support team