This issue has been discussed several times, but I haven't seen a post that describes my experience. I see this behavior on FM8 and FM9, Windows XP and Vista.
FrameMaker represents non-breaking spaces as character code 0x11. This is not a legal Unicode character, so XML saved from FrameMaker with non-breaking spaces will fail to validate. In fact, FrameMaker will fail to re-open documents with this character. This is unfortunate, but I can accept it.
Unicode specifies character code 0x160 as a non-breaking space. I can insert this character in body text and variable definitions. FrameMaker treats this character as a non-breaking space. (It does not display as a non-breaking space text symbol, but provides the behavior of a non-breaking space). Other processing tools also respect this character as a non-breaking space.
However, upon saving to XML, FrameMaker converts character 0x160 back to character code 0x11. So I'm back where I started. I can no longer edit the XML document in FrameMaker, nor is the XML valid and usable in other tools/workflows.
I've played with the "character map" read/write rule to attempt to get FrameMaker to write non-breaking space 0x11 as Unicode 0x160. But FrameMaker writes 0x11 back to the XML.
Is it reasonable to expect that FrameMaker retain Unicode character 0x160 on XML round-trip? Am I missing something? Of course, this is an issue for several lower-ANSI FM characters, including non-breaking spaces and hyphens, thin spaces, and forced returns, which FM writes to XML as illegal Unicode characters.
-Alan
--
Alan Houser, President
Group Wellesley, Inc.
412-363-3481
www.groupwellesley.com
1
Reply
]
AdChoices