XML parsing error: not well formed (invalid token) (error code 4)

Unless you are doing something very unusual with the form, this sounds like a bug. Send this one to Adobe support for verification.

In the mean time, can you build a simple form and use the same process without getting an error?

Is there something you can remove or change in the form that will make it work?

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/]http://www.adobe.com/devnet/acrobat/[/url]

Can the user who sent the form re-open it successfully?

George

I accidentally marked this as answered. I am hoping I can continue this conversation anyway.

Thanks for your replies!

This form is a questionnaire that is 9 pages long. The first page is simple, it is just some text fields to collect names and dates. The next 8 pages are tables with 7 columns, 1st column is question number, 2nd is question, third through 7th are check boxes to answer the question. Each check box is programmed to make the check boxes in the same question mutually exclusive (I couldn't get radio buttons to line up horizontally, and a book I have told me how to use check boxes instead.)

So, if I start removing pages, I can get the form to work. But when I start adding pages back in, I have the problem I described above. The user can distribute the form, and I can return the form, but when the user tries to import the data, she gets error messages.

I will send to Support, unless you can think of anything I am missing?

If the form is saved as Dynamic, you might try saving it to static and see if this makes difference.

Is it just the number of pages that seems to cause the problem, or is it a specific page? If it's the number of pages, then whats the number where the problem happens?

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/]http://www.adobe.com/devnet/acrobat/[/url]

It's already saved as Static. Maybe I will try it as Dynamic to see what happens.

I started rebuilding the file page by page. I started with Page 1, tested, then added to Page 2 and so on.

I was able to get all the way to Page 8 with no errors (distributing to myself, then filling out myself, then importing myself.) But when I added the last page, I got the XML parsing error. So I thought I had it figured out ... Page 9 is the problem. But then I tried through Page 8 with my user, and she got the XML parsing error. Then I had her try through Page 7, and again she got the XML error (even though I didn't when I distributed to myself.)

FYI - the line number and column referenced in the error code changes whenever I add and subtract pages.

From my experience, the most common XML parsing error is a missing, or extra angle bracket "<>". This kind of error is almost always reported in a different location than it actually occurs because it'll take the next matching angle bracket as the real one. Sometimes it doesn't get reported until the end when it figures out that the matching brackets are off.Is the reported line number at the very end of the XML? If this is the case then the error could be on page 1. Try mixing up the pages. Try it with pages 2-9, 3-8, etc.

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/]http://www.adobe.com/devnet/acrobat/[/url]

What would cause the angle brackets to be missing? I have not edited the XML manually, so I don't know what I could be doing to create errors in the XML. The line number is not at the end, it is usually somewhere closer to the beginning, on page 2 or 3. But I only start getting the error when I add pages past 4 or 5.

I will try mixing the pages around, and maybe doing a search in the XML for a "<>"The problem occurs when the completed form data is returned. I can't view that in LiveCycle designer, because it says the form was not created in LiveCycle Designer. What would be a good way to view the XML that is returned?

If the form can't be viewed in Acrobat or LiveCycle then you have to get tricky. For example, opening it in Acrobat 5, which will ignore the XFA part of the form. Then using a COS editing tool to extract the XFA data so you can look at it.

So, at this point it's better to see what the experts at Adobe can do with it. There's definately a bug in there somewhere.

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/]http://www.adobe.com/devnet/acrobat/[/url]

Okay, I'll turn it in to the experts, and I'll post the answer if I get one. Thanks a bunch for your help! -Kim

Hi - have a look at my post:

A Probable fix for: XML Parsing Error #4

Al

This is very strange. If I followed this thread correctly, it sounds like the user is returning the filled form in PDF format with the data inside (i.e. "submit as PDF"). When the PDF is opened, Acrobat crashes because of bad XML. The only way I can think of that this could happen is if there's a left angle bracket (<) that's somehow getting into the data un-encoded (usually it's encoded as <) and therefore causing the "bad XML" error on load when the data inside the PDF is merged into the form inside the PDF upon opening the PDF in Acrobat. Perhaps there's a field on one of the problem pages that is somehow pushing the bracket into its value?

Well this is what confused me, as if you did a 'straight' create form from using the original database table everything went perfect. And as I say, if I duplicated this Access table, gave it a new name, then went through the binding process again all was well. But why did the field in the LiveCycle file end up with a 'space' in it originally causing the problem.................? I wonder if this fixed "kimweintraub"'s problem....

Hello alscott,

My form was created in LiveCycle, and I checked all of the binding names to be sure there were no spaces. Of course there were none, because LiveCycle would not have let me create names with spaces. I appreciate the input, but your I don't think your solution applies since I have been 100% inside LiveCycle.

I have also used some of the other suggestions to look for possible errors, but can't find any. I did, however, isolate the problem to Page 8. When I remove all objects from Page 8, and leave a blank Page 8 in the form, it still works. Oddly enough, when I recreated all objects on Page 8, the error came back.

Another note, now when I add Page 8 back in (not blank, filled in with recreated questions + checkboxes to provide answers), I get the message "The file is damaged but is being repaired." Weird!

Next I am going to try to make an exact copy of Page 7 on Page 8 to see what happens. Stay tuned!

-Kim

Very interesting. When I copy all objects from Page 7 to a blank Page 8, it works. BTW - the objects copied (tables with text questions and checkboxes to accept answers to questions) are the same on every page of the form. I can't figure out what is different about the data on Page 8.

Next I will try (again) to change the text of the questions to the text that should be on Page 8, and see of the error returns.

Hi Kim,
I'm starting to suspect the Table in the Access file. But why only page 8, that is weird. When you re-created page 8 did you let LiveCycle create the fields itself straight from the Data View tab? I never got the 'damaged' remark.
Al

I am not sure what you mean by the Access file. I thought you meant MS-Access, but I am not using MS-Access. I am in LiveCycle only. When I recreated Page 8, I copied some tables from other pages. I mean tables that I insert into a form by going to Table/Insert Table on the LiveCycle top menu bar. Are we talking about the same thing? I am relatively new to LiveCycle, so I could be missing some terminology.

When I created Page 8, I selected objects in the Hierarchy view from Page 7 (tables with text and checkboxes), and copied them to Page 8. Then I changed the text to questions required on Page 8.

Note: When I go to the Data View tab, it is empty. I am assuming because I am not using an external data source?

Thanks! -Kim

If you didn't set up an external data source then you couldn't be using one. So you're good there. It's good that you narrowed down the problem page. Hopfully fixing it will simply be a matter of recreating it.

Tables in LivCycle are really just big complex sets of subforms. I can see how a bug in LC Designer (if one existed) might insert XML problems when table parts are copied and pasted around the form. Problems that don't become apparent until the form is submitted back to you.

I looked back through the comments and I didn't see if you had asked the user filling out the form to save it to a file, instead of submitting the form.
It would be interesting to see if the saved, as opposed to submitted, form has the same problem.

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/]http://www.adobe.com/devnet/acrobat/[/url]

Thanks, Thom. I'll try having the user save the form, that is if she can even open it ....

Unfortunately, when I recreated Page 8, I got the same error. It works when I send her a file that only goes through Page 7. But, I did recreate Page 8 by copying from prior pages, maybe I need to try completely from scratch.

I did have my user try to distribute the form where I had only removed Page 8 (which worked for me when distributing to myself), and she got the following errors upon opening the form (so now she can't even distribute it):

The 1st one read: Xml parsing error: not well formed (invalid token) (error code 4), line 1527, column 29 of file.

The 2nd one read: Cannot extract the embedded front ‘IPFCFI + MyriadPro-Regular;’ Some characters may not display or print correctly.

Now that makes me wonder if something strange is happening with fonts. At least that gives me another place to look.

Thanks,
Kim

I may have just had a breakthrough. I noticed that, no matter what I put on Page 8, I always get XML parsing errors. The errors are always reported to be somewhere in the first few hundred lines of XML.

I removed the first three pages instead of the last two, and it works when I distribute to myself.

So that leads me to this question. Is there a file size limit? I thought the problem was on Page 8 and/or Page 9, but could it simply be the file size? The problems always start when I add objects starting on second half of Page 8. When I add all of Page 8, the file size gets to about 900k

So, looking back through all of my test files, I noticed that when the file is smaller than about 825k it works, when it is bigger, I get XML parsing errors, as if the end of the file is being cut off in the e-mail transmission.

I am about to have my user try distributing Pages 4-9 from her PC, so I will report the results when she does.

Back to the drawing board, Pages 4-7 still do not work for my user, same XML parsing and cannot extract embedded font errors.