3

I'm facing a problem with a Web API I have that receives a PDF document (PDF form) as a base64 encoded string, makes it into a file, fills in some of the fields (using iTextSharp PdfStamper class) and sends the result back as a base64 encoded string, where it is again made into a file.

When I try to open this file/document afterwards with Foxit Reader I can still edit the fields, but when trying the same with Adobe Acrobat Reader, the fields are no longer editable.

When opening the property page and viewing the security properties for the document in Foxit Reader, it says that everything is allowed. However, when doing the same in Adobe Acrobat Reader, it says that commenting, filling in fields and signing isn't allowed (which it was prior to sending it to the API).

Unfortunately I can't dictate which PDF reader the end users are using, so I need this to be universal.

I can see that many others have posted about similar issues, but I don't see my particular issue in there.

Does anyone know what is going on here and how to get around it?

EDIT: code added

I'm doing this (tiny bit simplified, but the same):

PdfReader reader = new PdfReader("path to PDF form file");

stamp = new PdfStamper(reader, new FileStream("path to filled PDF form file", FileMode.Create));

AcroFields form = stamp.AcroFields;

IDictionary<string, AcroFields.Item> fs = form.Fields;

foreach (var f in fs)
{
    form.SetField(f.Key, "some value");
}

stamp.Close();

EDIT: sample PDF files added

The sample files are just something found on the internet, as I recall it was linked in another post in here.

I have tried to fill in 2 fields (firstname and lastname) in this PDF form.

The first file is the form created from base64 string.

d94b6076-983d-47db-b496-a0ba383deda4.pdf

The second file is the output after filling in the 2 fields.

d94b6076-983d-47db-b496-a0ba383deda4_filled.pdf

mkl
  • 90,588
  • 15
  • 125
  • 265
Aidal
  • 799
  • 4
  • 8
  • 33
  • Please show your code and share the pdf. Your description *sounds like* the pdf contains a usage rights signature which you break, and you most likely can fix this by using the append mode or by removing that usage rights signature. But that's all I can guess without code and pdf. – mkl Nov 01 '18 at 12:05
  • I have added some code now. – Aidal Nov 02 '18 at 07:53
  • According to your code you don't stamp in append mode. Thus, digital signatures will break. So the issue indeed can be that your pdf has a usage rights signature which gets broken causing Adobe products to allow very few features anymore. Without the pdf, though, I can only guess... – mkl Nov 02 '18 at 08:31
  • So, how would I go about doing what I'm trying to do, without upsetting Adobe products? – Aidal Nov 02 '18 at 08:47
  • Without the pdf, though, I can only guess... – mkl Nov 02 '18 at 09:03
  • sample files added – Aidal Nov 02 '18 at 09:20

1 Answers1

6

Your PDF contains a hybrid AcroForm/XFA form definition and a usage rights signature. Both facts complicate form-filling.

The usage rights signature

Your PDF contains a digital signature of a special kind, a usage rights signature. A PDF signed with such a signature (using a private key generated by Adobe for this task) signals to Adobe Reader that certain extra Adobe Reader features shall be activated when processing that very PDF.

If the signature is invalidated, though, Adobe Reader does not only not activate those extra features, it even de-activates certain other features otherwise active for unsigned documents.

You create your PdfStamper like this

stamp = new PdfStamper(reader, new FileStream("path to filled PDF form file", FileMode.Create));

That constructor does not initialize stamping in append mode. Thus, the stamped PDF is eventually written as a new PDF. This invalidates the usage rights signature and Adobe Reader restricts features when opening the PDF again.

By the way, upon opening the PDF with Adobe Reader, the program tells you so:

Adobe Reader pop-up

If you stamp in append mode, though, the usage rights signature is not invalidated. You can do so using a different constructor:

stamp = new PdfStamper(reader, new FileStream("path to filled PDF form file", FileMode.Create), '\0', true);

The final true activates append mode.

Alternatively you can remove the usage rights signature

PdfReader reader = new PdfReader("path to PDF form file");
reader.RemoveUsageRights();

The result has no usage rights signature anymore, in particular no invalidated one. Thus, Adobe Reader offers its standard features for this file.

Unfortunately saving XFA forms is not among them, so the PDF can be edited but not saved in Adobe Reader. This may not be what you want.

On these options also see e.g. this old answer; that answer talks about "Reader-Enabling" which is an Adobe term for "applying a usage rights signature".

Hybrid XFA/AcroForm form definition

The file contains a dual form definition, one AcroForm form definition which is the native PDF form type, and one XFA form definition which is a XML format using PDF merely as a transport container.

XFA form definitions offer more features but are only fully supported by Adobe software. In case of hybrid forms iText has a limited support to fill data into both form definitions. Depending on the exact features used in the XFA definition, though, this might fail.

In such a case you may want to remove the XFA form definition and only use the AcroForm one.

reader.Catalog.GetAsDict(PdfName.ACROFORM).Remove(PdfName.XFA);

On this approach please read this answer and this iText article.

Community
  • 1
  • 1
mkl
  • 90,588
  • 15
  • 125
  • 265
  • Thanks a lot for your a rich reply. The change to the stamper constructor was enough in my case. The PDF I was working with was another one than the one i linked, but the problem was the same. – Aidal Nov 02 '18 at 12:25