5 Replies Latest reply on May 17, 2011 6:23 PM by JustinCase.ftw

    Newline in form data displaying/printing as square

    JustinCase.ftw Level 1

      I've been making fill-in PDF forms and FDF data files for some years now but I'm seeing a new problem now.  In a form that has a newline character 0x10 in the data itself this will show up as a square (the usual indication of a non-printing ASCII character in Windows).  The newline character should be entered as '\r' in the FDF file per the specification and should appear in the multiline field as simply a new line (hard return).


      Unfortunately this is rather embarrassing for me as a consultant with this new client.  They're using Adobe Reader 9 and it's displaying one square per newline.  It's also printing this as well.


      For what it's worth, if you select the particular field and start editing it those squares go away.  If you tab out of the multiline field the squares show up again.  This bug is standing between me and getting paid for this project.  Please help.

        • 1. Re: Newline in form data displaying/printing as square
          JustinCase.ftw Level 1



          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

          16.344 TL

          (one\015) Tj

          (two\015) '

          (three) '



          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.

          • 2. Re: Newline in form data displaying/printing as square
            George_Johnson MVP & Adobe Community Professional

            I would be interested in looking at a sample document if you can email one to me at: acroscript at gmail dot com

            1 person found this helpful
            • 4. Re: Newline in form data displaying/printing as square
              JustinCase.ftw Level 1

              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 (?)

              • 5. Re: Newline in form data displaying/printing as square
                JustinCase.ftw Level 1

                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.