Filled AcroForm fields will not display correctly in certain Pdf Viewers

[StepKie]

Resources

Issue.zip

Reporting an Issue Here

PdfDocuments with AcroForms have display issues when opening in certain viewers / print preview on Apple.

Code snippet (found inside Issue.zip):

// Load PDF document.
var document = PdfReader.Open("sample_fillable_pdf.pdf", PdfDocumentOpenMode.Modify);

// This is also necessary, otherwise it is only visible when clicking into the field ...
document.AcroForm.Elements["/NeedAppearances"] = new PdfBoolean(true);
var nameField = document.AcroForm.Fields["Name"]!;
nameField.Value = new PdfString($"Test {DateTime.Now}");

// Save the document...
var filename = IOHelper.CreateTemporaryPdfFileName("sample_fillable_pdf");
Console.WriteLine($"Filename='{filename}'");
document.Save(filename);
// ...and start a viewer.
Process.Start(new ProcessStartInfo(filename) { UseShellExecute = true });

// The filled field will appear fine in Adobe Reader, Foxit etc.
// It will NOT be visible when opening in Apple Preview, Sumatra Pdf or similar.

Expected Behavior

When filling a document with an AcroForm, filled form fields should correctly display in all viewers.

Actual Behavior

Viewers where the field will be displayed correctly: Adobe Acrobat, Foxit Reader Viewers where it is NOT displayed: SumatraPdf, Apple Preview.

In these viewers, it displays correctly if one opens the original sample-fillable-pdf (in Foxit or Adobe for example), fills in a value for the field, and saves.

I cannot say more about other viewers since I do not have more pdf viewers available, but in our context (we create an app where we send a generated pdf to the printer, and it shows up empty in the print preview for iOS devices, while it looks filled on Android...

Steps to Reproduce the Behavior

Run the sample in Issue.zip. Open the produced sample-fillable-pdf.

Additional Information

A colleague of mine that is concerned with Pdfs for a living had this input to share, maybe it helps:

Das generierte PDF scheint auf den ersten Blick „ein Schuss zu haben“ – irgendwas stimmt nicht. Kann man u.a. checken, wenn man es in Acrobat Pro öffnet und gleich schließt – dann möchte Acrobat neu speichern. Ein solch erstelltes PDF, klappt dann auch mit Apple Vorschau (anbei).

Wenn Du beide PDFs in einem Texteditor aufrufst, kannst Du sehen, dass in „deinem“ PDF am Ende was fehlt – die FormType-Definition. Ob Euer Tool das über Parameter reinfummeln kann, kann ich nicht sagen. Aber schau in der PdfSharp Doku doch mal nach „FormType“, vermute da könntest Du was finden.

[StepKie]

@PDFsharp-Team any chance this can be looked at?

[TH-Soft]

This will not be added to PDFsharp in the foreseeable future. When setting the contents of an AcroForm field, it is up to your code to also set the representation.

[StepKie]

This will not be added to PDFsharp in the foreseeable future.

When setting the contents of an AcroForm field, it is up to your code to also set the representation.

@TH-Soft thanks for the swift response.

Can you specify what you mean with "set the representation"? I would be happy to do that in my code, but I am not sure what I am supposed to "set" so that it would be visible.

The reproducible sample is very basic, and it is not missing anything in my opinion.

Thank you!

[StepKie]

@PDFsharp-Team Sorry, one very last time, do you have an answer to the above question? Thanks again!

[ThomasHoevel]

AcroForms are not my area of expertise.

What I know: You have to add code that draws the contents of the fields.

What I don't know: How to do it.

It can't be done with two lines of code. And I'm the wrong person to tell you how.

[gavin-brown]

@Hottemax We are able to reproduce this issue. I see you've marked it as closed. Were you able to figure out a workaround for this issue or has it been addressed in a newer version of the library?

[StepKie]

@Hottemax We are able to reproduce this issue. I see you've marked it as closed. Were you able to figure out a workaround for this issue or has it been addressed in a newer version of the library?

No, I have no workaround, and it is still present in the latest version afaik.

I would be ecstatic if there were a solution!

I just closed it since a previous answer from an official side said "This will not be added to PDFsharp in the foreseeable future.", and I did not want to have it in my list of open issues, and did not want to clutter the PdfSharp issue list.

Feel free to reopen, that would be great!

[gavin-brown]

Thanks @Hottemax. I will re-open. EDIT: Never mind, it doesn't look like I can re-open the issue.

@TH-Soft I appreciate the work that you and the team have done on this library. This issue, if not fixed and no workaround, will cause us to move away from PDFSharp.

Based on your comment, it does sound like there is a workaround. Would you be able to share that? That would be greatly appreciated. Thank you!

[StepKie]

@gavin-brown I have reopened it, but as you see that TH-Soft had added the wontfix label, before...

[ThomasHoevel]

AIUI Adobe Reader will show the "appearance" you provide for the fields. If no appearance is given, nothing will be shown.

PDFsharp does not fully support form fields and code to add the appearance automatically will not be added to PDFsharp in the foreseeable future. This is no "issue" as PDFsharp is working as intended.

Feel free to implement this and give us a PR.

[gavin-brown]

Thank you @ThomasHoevel, that is very helpful information. Are there any samples in the documentation or samples that you can provide, showing how, when using the library, we can set the appearance in our own code? My apologies if that is an overly basic question, as I am newer to the library. Thank you again for your help.

[ThomasHoevel]

If we had samples, I'd have linked them here.

[packdat]

FYI: I have a branch here that attempts to address the issue described here (among other things). The "representation" of the AcroFields are drawn by dedicated Field-Renderers (one for each field-type).

Some instructions were added at the top of the Readme, I'd recommend checking out the mentioned test-cases to get a feeling on how to use the new APIs. I'm a bit hesitant at the moment regarding the creation of a PR, as i have the feeling the changes are not yet ready for production. It may give you a starting point to build upon though.

Side-note: The "representation" of an AcroField is defined by the AppearanceStream of a field's WidgetAnnotation. Please consult the Pdf-Reference for detailed descriptions.

[StepKie]

@packdat Hi, and thanks so much for your efforts - it looks like you invested a lot of time into your fork!

I'm a bit hesitant at the moment regarding the creation of a PR, as i have the feeling the changes are not yet ready for production.

It would be really great if your changes make it into PdfSharp, for us for example, this is the biggest blocker in our current MAUI project. I would be hesitant to build PdfSharp from your fork from source instead of pulling it in via nuget, as I can not be sure whether it will be synchronized with future PdfSharp releases.

Do you think a PR would be feasible? CC: @TH-Soft