Scripting not preserved when formatted text is copied into textboxes

[Paxtell]

Thank you again for your help resolving the previous issue we encountered.

PXCE Test.pdf

There has been an infrequent but major issue with PDF-XChange Editor (PXCE) we’ve encountered the last couple years, and we finally determined the cause last week. This is the only remaining issue we’ve had with PXCE and it appears a fix may be relatively simple.

We discovered that when a user is filling out an XFA PDF using PXCE and certain types of formatted text are copied into a textbox in the PDF, the scripting becomes corrupted and is not preserved when the PDF is opened in Adobe Acrobat Pro. Copying in the same type of formatted text into textboxes using Adobe Acrobat Pro or FoxIt is automatically converted into plain text. In PXCE, it appears the text is not converted, and the ASCII characters (e.g., &#xD) are conveyed into the XML, which is the potential cause of the corruption.

For example, if you open the attached PDF, which is a very short version of the form we have, you will notice a radio button group on the first page only. When any are clicked, a second and third page appear. If text is typed into the textboxes on the second or third pages in PXCE (or if text is copied from a Word document), the scripting is preserved, and the PDF opens in Adobe Acrobat Pro with the second and third pages present. However, if you select, copy, and then paste in text from the PDF (for example, from the yellow textfield in the PDF) using PXCE into a textbox, or you copy a table from a Word document into a textbox in the PDF, and the PDF is saved, the scripting is not preserved. When opened in Adobe Acrobat Pro, the second and third pages don’t remain as needed.

When this happens with our full form, only the first 3 pages are present when we open the form, even though it appears complete with many pages in PXCE. Our full form is located at (you need to download to your local drive first, since it is an XFA PDF): https://www.fda.gov/media/174458/download?attachment

Finally, if the formatted text that is causing the issue is typed over with plain text in PXCE, and the PDF is saved, the issue is resolved, and the PDF opens properly with scripting preserved in Adobe Acrobat Pro again.

This is a major issue, since our internal reviewers use Adobe Acrobat Pro, but many external users use PXCE when filling out their form. Let me know if you need anything else to help resolve this.

[TrackerSupp-Daniel]

Hello, Paxtell

Thank you for the detailed report. XFA is still not fully supported, but it is on its way. Unfortunately, we do have a heavy workload for the Devs in this area at the moment, and so I cannot promise a swift solution to this. I have ensured that they are aware of the issue, and it should be seeing some attention when it is possible.

In the meantime, the best I can suggest is that (assuming your internal reviewers do not need to directly edit the filled in forms) they could use the free version of our Editor, as a license is only needed for the use of premium editing features.

Kind regards,

[Paxtell]

I have an update on this. We found that it isn't the formatting, but the carriage returns that are causing an issue. Whether text is typed in or copied in, if a carriage return is added in PDF-XChange Editor, Adobe Acrobat Pro won't open it with all the scripting changes retained. This seems like a notable issue that would affect any form with a multiline textfield and that requires scripted changes to be saved.

Paxtell

[Tracker Supp-Stefan]

Hello Paxtell,

Thanks for narrowing that down!
I have passed the update to our devs, and they will take that into account.
However - as per Daniel's post above - I can not yet tell you when and how quickly that could be fixed!

Kind regards,
Stefan

[Paxtell]

Hi Stefan,

In case this helps the developers, we found an odd workaround for the issue. If all carriage returns in all textboxes after text is entered are replaced with carriage returns, this resolves the issue and allows Adobe Acrobat Pro to open the XFA PDF with scripting preserved. This is done by adding this line to the top of every Exit routine for every textbox in our forms:

root.variables.Functions.TextFieldProcess(this); //general text field code to run

We then added a root script object called "Functions" with a function named "TextFieldProcess" in it. This function replaces all carriage returns with carriage returns.

function TextFieldProcess (TextField){//textfield function
if (typeof app.pxceInfo !== 'undefined') {// only run in PDF-XChange Editor
if (TextField.rawValue != null) {//if text is present
TextField.rawValue = TextField.rawValue.replace(/(\r\n|\n|\r)/gm, "\n");//replace carriage returns with carriage returns
}//if
}//if
}//function

The only drawback we found is if an XFA PDF has a textfield filled that includes carriage returns in Adobe Acrobat Pro, then the PDF is opened and filled out more in PXCE, then it is reopened in Adobe Acrobat Pro, scripting is not preserved. This happens since we have the code running above only for PXCE, but we would like to see how often this situation occurs, since we would like to only run this process in PXCE until a fix is in place.

Kind Regards,
Paxtell

[TrackerSupp-Daniel]

Hello, Paxtell

Thank your for the followup, I will pass this up the chain to the Devs incase it is helpful. Before I do however, I just wanted to clarify; you mention replacing a carriage return with the same character, another carriage return. Is this a typo or is that actually what is being done here?
If that is the case, I would reckon that this issue is less one related to that specific character, and more that the act of making any change to these fields is able to "fix" the issue.
Can you try for example, selecting a field and adding a "space" character at the end, to see if that has the same effect?

Please let me know whether this was a typo, if my above idea was inline with your tests, or if something else happens.

Kind regards,

[Paxtell]

Hi Stefan,

Good idea, I didn't think of this, you probably know the answer. Yes, any replace "fixes" the issue.

Thanks,
Paxtell

[TrackerSupp-Daniel]

Hello, Paxtell

Thank you for confirming, that may help to make the resolution a bit easier. Its always good when every can reproduce the same issue, instead of getting 3 different issues from the same actions!

I should have mentioned, a Ticket was made for this as well:
RT#6829: Bug: Paste formatted text prevents XFA actions in other apps

While internal only, you can ask any member of the support team for an update by citing the ticket number above.

Kind regards,