Losing shift-returns in XML roundtripping

In addition to the techniques already mentioned, something else you can do

is map the forced return character to an entity.

--Lynne

Lynne A. Price

Text Structure Consulting, Inc.

Specializing in structured FrameMaker consulting, application development,

and training

lprice@txstruct.com http://www.txstruct.com

voice/fax: (510) 583-1505 cell phone: (510) 421-2284

Hi Jang,

My belief is that "soft-returns" are generally incompatible with XML roundtripping; however, I'm no expert with this subject and there may be some read/write rule that I'm not aware of.

The main problem, I believe, is that there seems to be no good way to represent such an artifact in a text file. Carriage returns have their own characters (ASCII 10, 13, or some combination thereof), but soft returns seem to be a left up to the authoring application (Word, FM, etc) to figure out and recognize. In a MIF file, a soft return is indicated by the following entry:

   <Char HardReturn>

...but who knows what that really is? When you save a document to flat text format, it seems to just convert to a regular carriage return.

According to sketchy information in wikipedia, there is a unicode character to represent a soft return. However, even if so, you would have to count on applications to recognize and respect it, which FrameMaker apparently does not. At least, not with its default behavior.

All that aside, I believe it is generally poor practice to have any forced line return that is not delimited by an element boundary. That said, DITA apparently provides elements such as <codeblock> > <ph> that do allow paragraph breaks, so maybe this isn't a solid rule. Of course, I'd assume that the DITA example would expect normal carriage returns.

I'd say that if the only reason for a soft return is to start a new line, there is no good reason to use them. The simplest answer may be to get rid of them. In all my conversions to structured content, that has been a top item on the to-do list.

Russ