Item5103: TMCE replaces non-breaking space with normal space.

Today I stumbled over another case where TMCE editing killed topic formatting on save, in two successive steps.

Occasionally, I write a non-breaking space   instead of a "normal" space, to avoid an unwanted word wrap, or as a placeholder, maybe several in a row. Another example is forcing a "table header" formatting for an empty element, like the following (I'm giving verbatim first, because some poor soul might inadvertedly destroy the example with TMCE)

| *Col1* | * * | *Col2* |

Col1		Col2

On the first save, the   is replaced by a simple blank, so that the heading now reads:

| *Col1* | * * | *Col2* |

This still looks as desired. But on the second save, the boldface space is gone, and the cell is formatted as plain empty cell.

Another use case where I've found   in our TWiki was to disable a setting, but leave it "visible":

   * Set FOO = bar

Regardless of verbatim, such a setting is ineffective. If not in verbatim, however, after a save the setting takes effect. Morale: Don't try to outwit TWiki, or TMCE will outwit you.

TMCE allows to explicitly add a non-breaking space with its "insert custom character" menu, but they enter the topic as a simple space.

The TWiki web in the distributions has 51 occurrences of  . If one of these is edited with TMCE, their formatting might be weird.

I know that TMCE can hardly be prevented from replacing a S with a S, because that's what the encoding means. But a non-breaking space is not a space!

-- TWiki:Main/HaraldJoerg - 09 Dec 2007

We also use the nbsp often in empty table headers. Would not want to loose those. Seems this character needs special TLC.

-- TWiki:Main.KennethLavrsen - 10 Dec 2007

An unprotected nbsp is taken through into the HTML edit. Once there, it is the same as any other nbsp. When the conversion back to TML happens, whitespace is optimised and nsbp's collapsed except where they are critical to TML.

Because nbsp plays a critical role in the conversion back to TML, I really don't want to change the way it is handled. On the flip side, protecting nbsp (so it appears as   in the editor) would make a bit of a mess of the edit.

I appreciate there are a lot of topics that have never been edited using TMCE, but there's a tradeoff between maintaining 100% compatibility with old topics, and making the editor maintainable. I can't think of a simple solution to this.

Confirmed.

-- TWiki:Main.CrawfordCurrie - 14 Dec 2007

Protecting nbsp (so it appears as   in the editor) may not work as expected - see Item1662.

-- MichaelTempest - 24 May 2009

It is possible to protect nbsp by wrapping sequences of one or more non-breaking spaces in a span with a dedicated class (e.g. WYSIWYG_PROTECT_NBSP) when converting TML to HTML. That provides enough information for WysiwygPlugin to differentiate between nbsp's that come from the original topic text and nbsp's that come from WysiwygPlugin's conversion to HTML.

However, as CrawfordCurrie said, <span class="WYSIWYG_PROTECT_NBSP">&nbsp;</span> is rather horrendous.

-- MichaelTempest - 30 May 2009

There is a lot of horrendous stuff out there when it comes to WYSIWYG implementation, but I don't think the protected span class mentioned here is particularly bad. Nobody will know/care, unless they're trying to debug or make sense of the html<->tml chatter.

I think fixing this bug in this way would make more users happy than there are developers for our whole project

-- PaulHarvey - 01 Jul 2010

I've tried to fix this by protecting NBSP using the standard protection code of TML2HTML.pm. That part works, and TMCE preserves the nbsp, however upon save, the HTML2TML process removes the protected nbsp anyway. So far I've been unable to find where the protection is lost. The bug is actually in WysiwygPlugin.

-- GeorgeClark - 27 Apr 2012

Commenting is disabled while not logged in