Text wrapping not occurring in multiline text field with CRLF chars

[BigWinnie]

I've scoured this forum and google trying to resolve a data formatting issue in a multiline text field.

I have an editable PDF document with multiple multiline text fields all with the same settings (see pic "multiline text field settings.png" below)

An example data used to populate one of these form fields plus the actual data whereby I know the "\r\n" is being translated into "CRLF" (proved using Notepad++).

multiline text field settings.png	Sample input	Data In Form Field
	Shortness of breath - normal activities\n\nSleep Apnoea\r\nDisturbed sleep\r\nSnoringLung Condition:\r\nRequires Home Oxygen\r\nCurrent / Ex smoker (circle)\r\n

What I'm seeing in the populated document  vs what I want to see is shown in the table below. The screengrabs are from the same document, one where it's just been generated in the browser, the second where it's generated in the browser but I've clicked in and away from the field, and the third after saving the document locally. What I want is to consistently have what is presented in the middle image without having to click into the form field. Also upon saving it should not revert back to the single line non-wrapped output.

Just Generated in browser
Click in & Out of field whilst still viewing in browser ** target display  **
Post file-save viewing viewing in Adobe Reader

I've spent half a day so far scouring for answers, recreating the form fields, changing the field settings on/off, changing font type and size.

And I know when I manually enter data into this field (ie via Adobe Acrobat Pro or Adobe Reader) the correct behaviour occurs. It's only when I'm programmatically populating that I get this issue.

I've even taking this very form that's been filled in, changed the settings so the correct behaviour is displayed, cleared the content, and used that as my new baseline form to populate, but alas no change.

Using: Win 8, Adobe Acrobat XI Pro

[BigWinnie]

I should also mention that I've tried playing around the CRLF chars using "\r", "\n", "\r\n", "\r\r", and "\n\n" to see if that may cause a change in the presentation experience.

[Bernd Alheit]

How do you populate the form?

[BigWinnie]

Currently this is being generated via Salesforce using an app called Vlocity.

I've reached out to Vlocity support also for assistance.

I've also written some javascript for use internal to the document that is called on various actions Will Close|Print|Save and Page/Open. The script loops through all the form fields seeking out multiline text fields, resetting the multiline attribute False|True and pasting the data back again. Outside of Salesforce PDf rendering this fixes the problem.

Now also trying to get SF to fire the javascript.

Ideally though I don't want this javascript in the doc but get the data to wrap properly on the CRLF chars.

[Bernd Alheit]

Looks like a problem of this app.

[Test Screen Name]

Definitely an app issue. Here's some background (technical).

A form field actually has its information twice in a PDF. One time is just the value (a string). The other is the appearance: a series of graphics including text and boxes, to show what it looks like.

When you open a PDF in Acrobat or some other filler you see the appearance (graphics). As soon as you start to fill it, the value (string) is used to let you type. Once that field is finished, the new value is used to make a new appearance.

So...if you open a PDF and a value is wrong or missing, but it all goes right if you click on the field, nothing is wrong with the viewing app. Rather, this shows that the app which made or last filled the PDF did a wrong appearance.

Some apps, like Apple Preview, don't fill in an appearance: the field us blank until you click on it. In this case the app (Vlocity?) makes an appearance which is usually right, but doesn't know what to do with new lines. Acrobat fixes it as soon as you visit/change a field.

[BigWinnie]

Thank you [Test Screen Name], what you say makes some sense, though I've not seen any code on the interwebs that allow you to both set the value AND set the appearance. I'd really appreciate If there's something you can share that'd enlighten me to achieve this.

I will also pass this on to vlocity to see if they can make some progress with setting this appearance for form fields.

The dumb thing is once upon a time when I was starting with this form, we (myself with vlocity) got the output to work correctly doing nothing more that using the CRLF (\r\n) chars. Unfortunately I lost that version of the PDF otherwise I'd copy/paste the form fields between docs with the hope they'd work.

[BigWinnie]

I'm also putting this javascript code snippet out there as it might help others (and a place for me to find it again). It's what I've tried to use to change the appearance based on different Actions. This loops through all the form fields in the document seeking multiline text fields. It then takes a copy of the current data value of the field, changes the multiline setting to reset it, then puts the data back in case the data in the field was corrupted by the multiline setting change.

for (var i = 0; i <= this.numFields; i++){

     var fld = this.getField(this.getNthFieldName(i));

     if(fld != null) {

          if ( fld.type == "text" ) {

               if ( fld.multiline == true) {

                         var mv = fld.value;

                         fld.multiline = false;

                         fld.multiline = true;

                         fld.value = mv;

               }

          }

     }

}

[Test Screen Name]

This will work... But only if the PDF is opened by a viewer that handkes JavaScript. So.. A solution for yourself and a solution if you are fixing the files to distribute, but not a solution if you distribute the files directly.

[BigWinnie]

Thank you Test Screen Name​, this echoes my experience whereby I've been unable to get the app doing the generation to fire the javascript function either directly or through any Action. Hmm, what to try next, of that I'm unsure.

Ideas anyone?

[BigWinnie]

What I have not yet shared, silly me, was this issue has appeared working with Chrome (Version 61.0.3163.100 (Official Build) (64-bit)) as the browser in which the PDF is presented.

I have subsequently tried this on Internet Explorer 11, and funny enough the problem disappears, either because the Page/Open javascript runs, or because the browser somehow resolves the appearance issue.

Unfortunately IE is not supported with Salesforce post Dec 2017 so this is not a viable long term option.

Currently I'm left with the save the file locally, open the file to cause the javascript to run, and then save the document again; crude but works.

[Test Screen Name]

IE uses Acrobat Reader, so the JavaScript is run. Non Adobe viewers like Chome MIGHT have JavaScript support and MIGHT include the methods you use which MIGHT have an effect. They MIGHT ignore appearances completely. Indeed they MIGHT (and often do) completely ignore form fields. All bets off with non-Adobe software.

[BigWinnie]

Something I've noticed since. I have run the Preflight test "Form field does not have appearance dict" which has resulted in showing that the multi-line text fields are missing their appearance dictionary. Now I have not found a way to recreate this appearance dictionary other than by allowing Adobe Acrobat Pro to create the fields in the document when no other fields exist, then duplicating the fields where I need another multiline-text field.

Anyone else know how to recreate missing appearance dictionaries for form fields by other means? If so, feel free to add to this post.