Losing shift-returns in XML roundtripping

Report · Mar 16, 2012

Hi

In a couple of locations - mainly table cells - my customer is using shift-returns to spread the data over multiple lines. The table cell does not currently allow a paragraph. But when the files get converted to XML and back (which will be part of the translation process), the shift-returns are eaten by the conversion process. Is there a way to prevent this ?

Ciao

Jang

Report · Mar 16, 2012

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:

...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

Report · Mar 16, 2012

Hi Russ,

I was more or less afraid of that. I should of course have known that this was bad practice from the start. Oh well, I will have to introduce another element in my EDD and scan all the files that were already created for occurrences of soft returns. The good thing is that I have only used them in case nothing else seemed to work at the time (except introducing a new element and format). The bad thing is that the entire repository of elements has been roundtripped to XML, so I cannot use a search - I will have to check all the tables to see if they are still OK.

Ciao

Jang

Report · Mar 16, 2012

Jang,

This may or may not fit into your situation.

In my EDD, I have an emtpy element named Br whose sole purpose is to indicate a line break. The EDD sets the format rules to Text Range in all contexts and its suffix to \r, which is Frame-ese for a return. One could do the same thing by making the \r a prefix instead. Of course, you need to edit your EDD to accommodate the Br element wherever it is needed.

The advantage of this approach is that the element survives roundtripping, because it is simply an element. The disadvantage is that the break does its thing only within FrameMaker, because it uses a property of the EDD to express it.

An alternative is allowing paragraphs within table cells. Both solutions require having the ability to edit the EDD and DTD.

Van

Report · Mar 16, 2012

Hello Van,

This is a good idea - I do not really want to allow a <para> in my table cells, as the <para> then allows an image and some other stuff that I never want to see in a table cell. It is not an issue that it only works in FM, as the only reason for roundtripping to XML is sending the materials out for translation and then importing them again. The translation tools do not care - or should not care - about formatting at all and they will leave the elements alone.

I do have access to the EDD and DTD, as I created them from scratch in the first place.

Thanks

Jang

Report · Mar 16, 2012

Jang,

Another solution is to create another element that mimics a paragraph but is used only within table cells, such as tablepara. Then give it the same allowed structure as a regular paragraph but without images. This also allows a writer to simply press the Return key to create another tablepara without having to insert soft returns.

Because you are the master of the EDD, you can decide which is the better approach.

Van

Report · Mar 16, 2012

Don't know if this was already mentioned, but you may want to take a look at the "preserve line breaks" rule.

...scott

Sent from my phone. Please excuse any typos or unexpected brevity.

Report · Mar 18, 2012

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