I've set up another development computer (Windows XP Pro) and installed Adobe Reader 9.4 on it. I've been able to reproduce the error locally and consistently now.
I've tried toggling the "Use Local Fonts" preference, didn't work.
I've tried to use a variety of fonts like Times New Roman and Arial, didn't work.
I've tried to turn off the font embedding, didn't work.
No matter what, if attempting to view the form in a newer version of Adobe Reader (like v9) then the newline character in a multiline text field will appear and print as an open square (box). Older versions (v4, v5) of the Adobe Reader and Acrobat display correctly.
To me, this is a bug in the newer versions of Adobe Reader.
I've even used a binary editor to view the content of the PDF files themselves to verify the contents. As expected, the '\r' character data is representing the newline character in the form data section so it's not that. In another section of the PDF it shows up as...
/Arial 12 Tf
2 46.4113 Td
This is the octal representation for 0x0D or ASCII 13 (rather than 0x0A or ASCII 10). But this appears to be the method that Adobe does for displaying what is in effect a hard return or line break within a multi-line text field.
And yet, there's a bug in newer versions of Adobe Reader in displaying this.
It's going to be a major pain to now break up the two newspaper-style columns that I've created for this application, replacing this with "one text field per line" down the page.
Some help here would be useful.
1 person found this helpful
I would be interested in looking at a sample document if you can email one to me at: acroscript at gmail dot com
Out of sheer frustration I'm just trying font after font...
Changing to "Courier SWA" on one of the multi-line fields seems to work as expected. I'll continue to see what other fonts don't suffer from this anomaly. I've attempted to choose what I thought were safe fonts like Times New Roman, Verdana, Arial, etc. but so far only the Courier SWA appears to be behaving. I suspect that the object optimizer during the save tries to remove as much "unused" character definition data as possible and that it's confused about the ASCII character set that's below 32 (space). But maybe the courier font isn't optimized like this since it's a fixed-width font (?)
Thanks for your help.
What I've found out is that I can export the FDF data, save it as a file and then double-click the FDF file to then launch and re-populate the field data. In this way it seems to behave itself in Adobe Reader 9.
This seems to validate the if I continue my web application and populate the data from the FDF stream them it ought to work as expected. They just won't be able to save the output PDF+FDF data.