tinymce issue - leading and trailing spaces get truncated after saving DCR

I am working on TeamSite 7.3.1 on Linux.
I have some DCRs having textarea field where Tinymce is enabled.
Facing issue - leading and trailing spaces of textarea content get truncated. I need those as part of content.
> I edit DCR, add some leading and trailing space to textarea content.
> save the DCR
> edit it again

Leading and trailing spaces of textarea content get truncated.

Is this a Tinymce product issue?
or
Is there any setting that may resolve this issue?

Any help in this regard is appreciated.

Regards,
Gauri

Find more posts tagged with

Comments

Rick Poulin

In HTML, multiple white space characters are irrelevant. Collapsing them to one produces the same rendering. TinyMCE is an HTML editor, so it says "if whitespace doesn't matter, let me clean that up for you". In HTML, if you want to force whitespace, you have to use  . There's a TinyMCE button to add those in your content. Not sure why you expected it to behave differently?

gauri_j

Thanks rpoulin for response.

For my content, spaces do matter. I want to force white space as part of content.

But, even adding " " as leading and trailing space does not work. Even those are truncated.

Is this a product bug?

Found this thread:

http://www.tinymce.com/forum/viewtopic.php?id=26345

Regards,

Gauri

Adam Stoller

Not a solution, but a potential work-around...

Is the DCR content being processed by a PT to generate an HTML file, pushed into a DB, or processed directly from the XML by an AppServer (e.g.: LSDS)?

Regardless, you may be able to pre- or post- process the conent by combining a bit of user-training and code - where if you want the leading (or trailing) non-blocking white-space to stay you precede (or follow) it with a period (or some other punctuation character) and then have the PT or rendering code strip out the leading (or trailing) period (or other punctuation character) if present.

Like I said, not a solution, but a potential work-around...

gauri_j

Hi Ghoti,

That seems to be a work around. Not sure if business users will be ok with it.

Any pointers as to whether we can treat this behaviour (truncating leading and trailing spaces) as TinyMCE product bug?

or may be call it its default bahavior...

Regards,

Gauri

gauri_j

My code does not have a PT. There is a custom application which takes DCR as XML and processes it.

-- gauri

Adam Stoller

The same approach as described for the PT should apply for a custom application that processes the DCR as XML.

An alternative to the work-around [hack] I suggested would be if you can identify specific textarea fields that need leading (or trailing) non-blocking spaces - and then modify your custom application to always insert them at the beginning (and/or end) of the content read in from the XML (DCR) when rendering the output.

For example - if you know that certain fields should always have 1 (or N) leading non-blocking spaces you could make sure that the names of those fields all use a special prefix (or suffix) that your custom application can pick up on; e.g.: "_xpad_....". So you could name a field that would otherwise be called "widget_description" to be "_xpad_widget_description" or something along those lines.

This would put the onus on the DCT developers to make sure that such fields are appropriately named, but the users of the DCT wouldn't have to know / care about it - it would just happen behind the scenes.

(and no, I don't have code for handling this on the front-end to provide, nor am I sure how much effort it would take - it's just a suggestion for how to approach the issue)

If you want to try to register it as a bug you can, but as TinyMCE is a 3rd-party product, the likelihood of getting a solution from HP for it is minimal at best.

gauri_j

Thanks Ghoti for response.

In my case, spaces (leading or trailing) are part of content and their count is not fixed. It is user's wish.
So, any automation does not seem to be possible.
Will see if the workaround of adding a character (before leading spaces and after trailing space) is feasible. Will need some additional custom code the ger rid of this char when the DCR gets processed.

Regards,

Gauri

Adam Stoller

Another option, that might be better / easier for users, is to provide a separate field in conjunction with the textareas to specify leading (and/or trailing) non-blocking white-space characters - e.g. something like:

<item name="nbsp" pathid="nbsp">
 <label>Leading Whitespace Characters</label>
 <text><default>0</default></text>
</item>

And then have your rendering application check that fields value and use it as an iterator for inserting nbsp entities.