These forums are now Read Only. If you have an Acrobat question, ask questions and get help from one of our experts.

Data enclosed in CDATA tags as part of xfdf file does not display.

magik
Registered: Sep 19 2008
Posts: 12

Hello All,

I have a peculiar problem with data not displaying when viewed with Adobe Reader version 7.0 and higher.

Basically we have fqdf files that contain data that is enclosed in CDATA tags. That is because of foreig characters that would normally break up the xml. But, when we try to display the fqdf files in Adobe Reader 7.0 and higher, even though the xml is formatted correctly, that data does not display in the reader.

Now, if we take an fqdf file with no CDATA tags, the data displays fine.

I don't know what happened from the 6.0 verstion onwords that the data withing the CDATA tags doesn't show anymore. The 6.0 version of the Reader was displaying that data just fine.

So my question is, does anyone know why this is happening? What changed in the Reader that doesn't allow the data to be displayed?

And if this is something that Adobe can't remedy, what is the workaround for this in order to have the data enclosed in CDATA tags to show?

Anyone have any insight on this? Would greatly appreciate any info.

Thank you.
Magic

My Product Information:
Reader 9.0, Windows
George_Johnson
Expert
Registered: Jul 6 2008
Posts: 1876
magik wrote:
Basically we have fqdf files that contain data that is enclosed in CDATA tags. That is because of foreig characters that would normally break up the xml.
What do you mean by this? What characters, exactly, are causing problems? Can you give an example of text that would cause trouble if not placed in a CDATA section?

George
magik
Registered: Sep 19 2008
Posts: 12
The is a number of characters we use in our data, like apostrophes, plus signs, $ signs and others that then collide with the xml. So in order to make that data "valid" we enclise them in the CDATA tags.

Here's a file I'm trying to view in Adobe Reader 9.0. It's a bit long, but all it is, is just a list of fields with data, that's all. And all of them are enclosed with CDATA tags. That's because we don't check for the "foreign" characters, but rather make an assumption that they will show up at some point.

If you display the the below in IE, you'll get valid xml. Yet Reader won't display the data.

<?xml version="1.0" encoding="UTF-8"?>
George_Johnson
Expert
Registered: Jul 6 2008
Posts: 1876
I just did a quick test (in Acrobat 7.1.0), and apostrophes, the + sign, and the $ sign do not need to be treated specially. The angle brackets and the ampersand (&) do, so you could replace any of those with their corresponding character entities (< > &). It can't hurt to do the same for the double quote and single quote characters as well.If you are still having problems with certain characters, can you post a smaller XFDF that demonstrates this? Just one field will do.

George
magik
Registered: Sep 19 2008
Posts: 12
But the question remains, why doesn't that data display in the newer versions of the Reader?

Here's a shorter version of the above:

<?xml version="1.0" encoding="UTF-8"?>Net Over/ShortI know, in that excerpt there is not "foreign" characters, but that shouldn't stop the Reader from displaying the data as it is. I mean, this is straight xml. Why would Adobe stop processing CDATA tags properly??
George_Johnson
Expert
Registered: Jul 6 2008
Posts: 1876
magik wrote:
But the question remains, why doesn't that data display in the newer versions of the Reader?...

Why would Adobe stop processing CDATA tags properly??
I don't know. You'd have to ask Adobe. Are you looking for an answer to these questions or are you seeking a solution?

George
magik
Registered: Sep 19 2008
Posts: 12
I'm seeking a solution. Or a workaround as a solution.

We wouldn't have used the CDATA tags if they wouldn't allow us to enclose the "foreign" characters in order to display the data easily.

What you suggested with replacing the characters with their character entities is good, but it would mean, that we would have to recode our functions, which is not something we wanted to do. If worse comes to worse, we'll code it that way, but I'm trying to see if there's an easier "fix" to this, as this has worked in previous versions of the Reader.
George_Johnson
Expert
Registered: Jul 6 2008
Posts: 1876
I think worse has indeed come to worse. Recoding is the only solution I can suggest.

Besides working, it will have additional benefit of making the XFDF smaller by ten bytes per field. :^)

George