It is enough to examine the Document.Form property for it to be created in the output file even though there is no form in the document. For example:
var pdf = new Document("Empty_pdf.pdf");
if (pdf.Form?.Fields.Any() == true)
{
Console.WriteLine("pdf has form fields");
}
pdf.Save("output.pdf"); // output.pdf has a AcroForm
The expected behavior is that a form is not created in the output file.
var pdf = new Aspose.Pdf.Document(@"empty.pdf");
if (pdf.Form?.Any() == true)
{
Console.WriteLine("this line is not reached");
}
pdf.Save(@"empty_form.pdf");
Here is the output document: empty_form.pdf (38.3 KB)
as you can see it has the following:
I looked at the pdf specification - there is no explicit indication that if a document has no fields, then there should be no corresponding entryes. AcroForm entry Descr.png (49.8 KB) Int Form dict.png (68.3 KB) Int Forms.png (62.0 KB)
I understand, but I expect Aspose to not modify the PDF to include an AcroForm if one has not been intentionally added to it. I expect to be able to check whether a PDF has a form in it without causing the creation of one.
My current workaround is to create two instances of Document - one to check for the existence of a form and one to do other processing i.e.,
bool hasFormFields;
using (var pdf = new Document("input.pdf"))
{
hasFormFields = pdf1.Form?.Any() == true;
}
using (var pdf = new Document("input.pdf"))
{
/// do other stuff
if (hasFormFields)
{
/// do some more stuff...
}
pdf.Save("output.pdf");
}
But this is a hack and is wasteful in resources and performance...
@Buffer2018 Forms -General.png (78.1 KB)
As I understand your vision - if there are no fields in the document, we should consider that it does not have an interactive form.
The current interpretation in the library - if there are no fields in the document, we consider that it contains an interactive form with zero fields number.
And both of these visions do not violate the specification.
I will ask the development team for their opinion on this issue.
According to the given code fragment - You can check the number of fields and compare it with zero (if I understood your request correctly)? Yes, entries are added to the dictionary, but this is not a critical value in terms of time and size.
I meant I consider creating two Document objects of the same PDF file to be wasteful - especially if we’re talking about a big PDF.
I expect a PDF without an AcroForm inside it to have a null value in its Document.Form property or alternatively to expose a Document.HasForm property that indicates whether the document already has an AcroForm element inside it.
For now, we are using the workaround mentioned above, but it would be very helpful to know whether a PDF file has an AcroForm inside it without needlessly creating it.
@Buffer2018
The following approach should be used.
var pdf = new Document();
pdf.Pages.Add();
if (pdf.Form.Fields.Length > 0)
{
Console.WriteLine("pdf has form fields");
}
else
{
Console.WriteLine("pdf has no form fields");
}
But this is exactly the cause of the issue. Saving a PDF that did not originally have any form elements after checking it results in a PDF that has an empty form element. The only workaround is to check the form element in another, separate instance of Aspose.Pdf.Document. There should be a way to check the existence of a form element within a document without creating one inside the instance.
because 3rd party analysis tools report this form as a potential vulnerability. this can introduce strange result where a file before our processing does not have a form element and is not reported to have a potential vulnerability and post-processing will be reported as having a potential vulnerability. To us this is of course an unacceptable result… So for now, we are using the workaround I described.
My vision is for Aspose to behave according to the Hippocratic oath - “First, do no harm”
@Buffer2018
Thanks for the clarification.
Can you specify these tools and the details of the corresponding check? I am interested in this because if such a thing exists, then I will create a task as an improvement, otherwise as ainvestigation of the user’s wishes.
@Buffer2018
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): PDFNET-58723
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
It is not positioned as a mistake here - it just does not match your vision.
Created a task for investigation
There were no strong arguments from the user that it should be implemented exactly this way, so I qualify this task as: ‘study the need and implement it if there is a need’. Of course, it should be taken into account that there is no breaking change, since many users now assume the current behavior.