XML import deletes whitespace after xref element

[Russ Ward]

Hi,

FM10 not patched, WinXP SP3

I've bumped into a very serious problem that I am able to replicate, but not solve. When I import (custom) XML, any whitespace following <xref> elements is deleted. I don't know if it exclusive to crossreference elements or any no-content elements... but for sure it is happening with xrefs.

Here is a zip with sample files with which I am able to replicate this. The XML file has two <xref>s separated by "and". When you import the XML (using the DTD, rules, and template provided), the whitespace before the "and" is deleted.

http://www.weststreetconsulting.com/downloads/test.zip

I disabled all my personal plugins and all DITA plugins that I could find, same thing.

I don't know if anyone has the time to look at this, but I'd be very appreciative if anyone could confirm the problem. This has caused a real mess in my source files that I can go fix using non-breaking spaces, but this is really a pain and very much suboptimal.

Thanks,

Russ

[ScottPrentice · Accepted solution]

Hi Russ...

This is a known problem for DITA files, and may also be the cause of the problem you're seeing. This has been fixed in the latest patch, as long as you're using an import/export client that has been rebuilt with the latest FDK libraries. (Presumably if you're using the default client, it should "just work" once you install the update.) I posted this to the framemaker-dita Yahoo group some time ago ..

----------------------

If you're using FM10 DITA (with DITA-FMx or not), you may have noticed that the spaces after inline conrefs are missing. Apparently FM10 introduced some whitespace normalization, that was a little too aggressive.

This may be fixed in a future update, but in the mean time you can fix it by making the following edit to the maker.ini file. In the Preferences section, change this ..

   RemoveExtraWhiteSpacesOnXMLImport=On

to this ..

   RemoveExtraWhiteSpacesOnXMLImport=Off

And all is right in the world once again.

---------------------

Hopefully this will fix your troubles .. but I'd install the update anyway, since that fixes a number of other bugs.

Cheers,

...scott

[Russ Ward]

Scott,

I assume you are talking about the 10.0.1 update. I installed it, but still see the problem (and yes, I am using the default client). However, adjusting that maker.ini setting did stop the behavior, so thanks a million. What an insidious problem... it was messing up hundreds of pages of content with me totally unawares.

Is there any consequence to having this setting as off? And why would you want whitespace normalization anyway, when we are dealing with literary content here?

Russ

[ScottPrentice]

Russ...

Yeah .. that's the update that "fixes" the problem. At least it did with DITA. I suppose it's possible that they (Adobe) didn't recompile the default import/export client with the updated FDK libraries. As far as I know, this was a problem in the libraries that were used with those clients.

The only reason that you'd want whitespace normalization is if you're working with XML files that are edited in other editors where extraneous whitespace may get added via "pretty printing" or other such nonsense. If your files remain in FrameMaker, you should be fine to leave this setting off .. I think it's basically the "old" method from earlier FM versions.

Cheers,

...scott

[Russ Ward]

IMHO, spurious whitespace and pretty-printing are totally incompatible with literary data and I can't imagine why anyone would ever engage such features. It seems that the assumption by the default setting (removewhitespace=on) is backwards and risky. I think the assumption should be that content was handled normally from the start. Anyway, I digress. I've turned it off and all seems well. I hope it wasn't doing anything else in there that I wasn't aware of. Thanks again.

[Russ Ward]

Here is a followup, somewhat related to the original problem. I need to vent about this and feel like starting a new thread, but I'll resist that urge.

Turns out, this new FM10 "feature" (which is turned on by default) will strip out any instance of duplicate whitespace and normalize all spacing down to single spaces. In addition, the changes happen without warning, so as soon as you resave the file, the changes are permanent.

I am quite frankly stunned that the software was released in this state. I've never seen any DTP or authoring software do something nearly this egregious... alter your content without any warning. I have lots of code samples and other such text in my documentation that uses monotype "<pre>"-type formatting, where whitespace is a critical formatting tool. It turns out this "feature" has wreaked havoc throughout my source files, costing me a day and a half to recover. If I didn't have FDK expertise and the backups I made just before moving to FM10, it would have taken much longer.

Bottom line, IF YOU IMPORT XML, BEWARE OF THIS SETTING! If whitespace is significant in your content, FM10 by default may damage your files. If anyone from Adobe reads this, I'd like to emphatically submit that this is a critical bug. An authoring program should never alter your text, at least without warning.

Russ

[Arnis_Gubins]

Russ,

File a bug report at: https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform&product=63

Also send a message to Kapil Verma (Product Manager - http://forums.adobe.com/people/Kapil%20Verma%20(FM%20PM)) and Rajat Bansal (Engineering Manager - http://forums.adobe.com/people/Rajat%20Bansal) for FM via the Forum private messaging.

[NakshatraB]

Hi Russ,

Did you evaluate using the "xml:space" attribute for elements that require preservation of spaces. If the xml:space attribute is set to preserve (i.e. xml:space="preserve")

FrameMaker would preserve the whitespaces in that element during XML import.

You might want to read more about it in the documentation link mentioned below:

http://help.adobe.com/en_US/framemaker/using/WSD7FBA378-86FB-49ad-82EA-CCCFF5CC9524.html#WSfdd6fcd10...

And some more info on w3.org- http://www.w3.org/TR/xml/

Regards,

Nakshatra

[Russ Ward]

Nakshatra,

Thanks for the info. The real problem is not so much how to turn it on and off... the problem is that it is on by default. That means when someone moves to FM10, they run the risk of having their content altered without warning.

Russ