Form fails to read in IE Acrobat Reader after activating license

Receiving an XML read error when streaming PDF form to IE browser after installing the Total.lic. There is no error when streaming to Firefox, but majority of our users are IE. When I was testing without activated license, I received no error from IE.

What bug has caused failure in content of PDF file that now I get an XML error?

The XML page cannot be displayed

Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later.


An invalid character was found in text content. Error processing resource

Attached files are 3 forms: 1 Original, 1 created With license, and 1 created with No active license.

Below are snippets of how I've activated licenses within my class. To create the pdf form without license I merely commented out the below code.

///

/// License reference for Aspose PDF Kit and PDF APIs

///

private Aspose.Pdf.Kit.License m_pdfKitLicense;

private Aspose.Pdf.License m_pdfLicense;

private void InitializeMemberData()

{

//Set the license files for Aspose PDF Kit and PDF APIs

m_pdfKitLicense = new Aspose.Pdf.Kit.License();

m_pdfKitLicense.SetLicense("Aspose.Total.lic");

m_pdfLicense = new Aspose.Pdf.License();

m_pdfLicense.SetLicense("Aspose.Total.lic");

}

I noticed that there is a large difference in the header of the form modified with an activated license as compared to the one created without a license. This is surprising as I expected a licensed creation would create a form more closely like our original. Instead, the header in the form created without the license closely matches the header in the original form we use as a template.

The error message we get seems to indicate that the bad character is a ‘%’ .

The XML page cannot be displayed

Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later.


An invalid character was found in text content. Error processing resource 'http://localhost:41513/IHFSystem/OpenHRA.aspx?IH...

%

I found two instances of % in the values in the new XML string in the header.

  • z,zz9%
  • %

I verified that % is a reserved XML character in some instances, like SQL, http://msdn2.microsoft.com/en-us/library/ms145315.aspx. Maybe IE treats this way as well?, maybe why Firefox doesn’t have an issue with opening the pdf in Reader, while IE gets this error?

1)Do you mean that there is an error when opening the pdf with license in IE? But no license is ok?

2)The error message is strange. Why will it report a XML error? Which version of Adobe Reader?

3)By the way, I have read the pdflicense and pdfnolicense. Both the head only has one ‘%’.

Best regards.

1)There is an error when using IE to open the pdf form created by an active Aspose license. If we turn off our license (like in trial) and create the pdf form then we can open it without any error from IE.

2)We only receive this error from IE and not Firefox. I have tested both Acrobat Reader 8 & Reader 7.. they both fail with same error. The same reader is being used whether in IE or Firefox because I have both browsers available on my system and I've set Reader as my default for pdf files.

3)Something is obviously different in the form created when we have activated the license as compared to when we have not. Whatever is added or omitted with an active license is causing IE to fail to open the pdf in Reader.

This issue is a show stopper for us and sadly only after we've purchased the license. We need a fix as soon as possible. I am online this evening so that I can work with you as much as possible. We are slated to release at end of this week.

Wondering if there's a status for this issue with our licensed version?

As further example of issue, place the pdf form created With License on a web site and link to it. Then follow link using IE and you should see the error noted. As well, I've found that even Firefox intermittently fails in this manner of viewing the pdf.

Please let me know of anything else I can possibly provide in support of fixing this. We are due to release in 4days and this obviously is a showstopper (we cannot release with unlicensed APIs).

What's the status on resolution to this issue? We are in show-stopper for our release using Aspose APIs.

Thank you for your prompt assistance.

Yesterday I was on a long journey.
But now I am working hard on this strange issue. And I hope i will solve this quickly. If i have any progress , i will inform you ASAP. And this is my msn dk_horse@hotmail.com . We could communicate by this.

Best regards.

I have tested the result pdf in IE 6.0 of windows xp and Adobe Reader 7.0.9. All is ok. What a strange problem!

Best regards.

I have previously sent you info on the versions we're using for platform in separate email.

Another issue we have come across - after deploying to Test system, Aspose APIs are failing to release file handles on files we're working with in multiple instances. To try to work-around that bizarre issue, we decided we would control the file handle by instead using MemoryStreams. Doing that showed more issues --- one of which is of interest, the error I get when trying to create the forms.

Could this be related to malformed pdf format that IE fails with?, or maybe this is separate issue when working with streams across the Form and FormEditor objects?

Error is - "Invalid pdf format:pdf head signature is not found!"

Snippet of code that this failure occurs in -

MemoryStream formTemplateFile = new MemoryStream(File.ReadAllBytes(formTemplateFilePath));

MemoryStream tempFormFile = new MemoryStream();

MemoryStream formOutputFile = new MemoryStream();

try

{

//Set the submit URL appropriatly

Form tempPdfForm = new Form(formTemplateFilePath);

FormEditor formEditor = new FormEditor(formTemplateFile, tempFormFile);

foreach (string field in tempPdfForm.FieldsNames)

{

if (field.Contains(SAVE_CHANGES_BUTTON_FIELD) == true)

{

bool isSet = formEditor.SetSubmitUrl(field,

ConfigurationManager.AppSettings["MyUrl"] + SAVE_CHANGES_PAGE);

}

}

formEditor.Save();

// Now set all the user info related fields.

Form pdfForm = new Form(tempFormFile, formOutputFile);

SetFormField(pdfForm, FORM_DATE_FIELD, DateTime.Today.ToShortDateString());

SetFormField(pdfForm, UserInformation.DataTag_FirstName, userInfo.FirstName);

SetFormField(pdfForm, UserInformation.DataTag_MiddleName, userInfo.MiddleName);

SetFormField(pdfForm, UserInformation.DataTag_LastName, userInfo.LastName);

SetFormField(pdfForm, UserInformation.DataTag_FullName, userInfo.FullName);

SetFormField(pdfForm, UserInformation.DataTag_Address1, userInfo.Address1);

pdfForm.Save();

File.WriteAllBytes(formOutputFilePath, formOutputFile.ToArray());

}

catch (Exception formException)

{

throw new PDFManagerException("Unable to auto fill form fields:" + formException.Message, formException);

}

finally

{

formTemplateFile.Close();

tempFormFile.Close();

formOutputFile.Close();

}

}

Please add one line before this call:


// Now set all the user info related fields.
<o:p></o:p>

tempFormFile.Position = 0;

Form pdfForm = new Form(tempFormFile, formOutputFile);

The IE problem seems not the same as this one.

Best regards.

ken:
Please add one line before this call:


// Now set all the user info related fields.

tempFormFile.Position = 0;

Form pdfForm = new Form(tempFormFile, formOutputFile);

The IE problem seems not the same as this one.

Best regards.

this positioning attribute did take care of the unrelated issue. I am still failing to access Form through IE. I have not problem accessing PDF files edited by pdf.kit - just PDF forms are the issue.

We have attempted using Aspose.Pdf.Kit published version 2.3.2.0 and still no resolve to this issue.

This is extremely frustrating that something as easy as activating a license has caused failure in content of the pdf form. As long as we do not have license activated then the form content is well-formed and without issue to IE. But we need the license activated for other file manipulations we do (eg. Extract) so that we don't get watermarks on results.

Crying [:'(]

I have reverted to 2.3.2.0 just to stay in synch with published release.

I have built a quick test app for your use. I am zipping and sending to you by email.

The test case has the debug command line parameters set, so all that needs to be done is run it in debug and then check local debug folder for created form. You can change the parameters in the project properties for Debug and set to use no license create of form.

command line parameters for failing form: TestFormDesigner8.pdf WithLicense.pdf ACTIVE

command line parameters to create without lic: TestFormDesigner8.pdf NoLicense.pdf EVAL

A solution to this licensing issue is of utmost importance. thank you.

I have reproduced the error and found the characters of the errors. I wish I could solve it tommorrow.

Best regards.

Wonderful! I will be eagerly waiting the fix so that I can install as soon as it is ready. Thank you.

Good news! I have fixed the strange problem. Please download the new dll in the attachment and test it.

Best regards.

Wonderful! this dll version is working for forms read via IE and Firefox browsers!

When will this become a published release?

The hotfix 2.3.3.0 has been published.

Please Fix.

I have found a similar issue when using the FormEditor class.

For an immediate work around, I make my last changes with the Pdf.Kit.Form class so that I don't receive the XML error. But if the order of my changes are Pdf.Kit.Form followed by Pdf.Kit.FormEditor the form fails to be read in an IE browser and gives the XML error.

Causes Error:

Form pdfForm = new Form(formFile, tempReadOnlyFile);

string[] fieldNames = pdfForm.FieldsNames;

foreach (string fieldName in fieldNames)

{

// This is temporary since the remove field is not working.

if (fieldName.Contains(SAVE_CHANGES_DESCRIPTION_FIELD) == true)

{

string newText = "This form is in read-only mode. The Save Changes button has been disabled";

pdfForm.FillField(fieldName, newText);

}

}

pdfForm.Save();

tempReadOnlyFile.Position = 0;

FormEditor pdfFormEditor = new FormEditor(tempReadOnlyFile, readOnlyFile);

foreach (string fieldName in fieldNames)

{

// Make the form read only by removing the Save Changes button and

// the save changes description from each page or where every they occur...

if ((fieldName.Contains(SAVE_CHANGES_BUTTON_FIELD) == true) ||

(fieldName.Contains(SAVE_CHANGES_DESCRIPTION_FIELD) == true))

{

// Remove doesn't seem to currently be working, so disable Save Changes button

// by setting the submit URL to empty string.

if (fieldName.Contains(SAVE_CHANGES_BUTTON_FIELD) == true)

pdfFormEditor.SetSubmitUrl(fieldName, "");

pdfFormEditor.RemoveField(fieldName);

}

}

pdfFormEditor.Save();

Work Around:

FormEditor pdfFormEditor = new FormEditor(formFile,tempReadOnlyFile);

foreach (string fieldName in fieldNames)

{

// Make the form read only by removing the Save Changes button

if (fieldName.Contains(SAVE_CHANGES_BUTTON_FIELD) == true)

{

// Remove doesn't seem to currently be working, so disable Save Changes button

// by setting the submit URL to empty string.

pdfFormEditor.SetSubmitUrl(fieldName, "");

pdfFormEditor.RemoveField(fieldName);

}

}

pdfFormEditor.Save();

tempReadOnlyFile.Position = 0;

// Must open and do final save with a Form object to work around issue where the

// FormEditor saves the XML headre wrong which I.E. doesn't like.

Form pdfForm = new Form(tempReadOnlyFile, readOnlyFile);

foreach (string fieldName in pdfForm.FieldsNames)

{

// This is temporary since the remove field is not working.

if (fieldName.Contains(SAVE_CHANGES_DESCRIPTION_FIELD) == true)

{

string newText = "This form is in read-only mode. The Save Changes button has been disabled";

pdfForm.FillField(fieldName, newText);

}

}

pdfForm.Save();