Non-breking hyphen: \x15 is not output to HTML5 - as is \u2011

[K.Daube]

Sparky Anderson alias Doug writes to me:

I use your ETB ( love it! ) and wanted to point out a bug.  When I right click and use the drop down menu to insert a non-breaking hyphen, it still breaks when I publish to HTML5.  Maybe I'm doing something else wrong, but it looks like ETB doesn't use x2011 when it tries to insert a non-breaking hyphen.

IMHO FM does not recognise \u2011 as a non-braking hyphen. MIF states:

<ParaLine 
  <String `Inserted by ESC,-, h (or ETB Insert Special Symbol): '>
  <Char HardHyphen>
> # end of ParaLine
<ParaLine 
  <String `Inserted by Unicode: ‑'>
> # end of ParaLine

My editor tells that in the Unicode the character is U+2011

IMHO this is a bug - and I guess the 'equal' treatment of \x15 and \u2011 was requested long time ago be others already. - although I can not find a corresponding entry in the bug base.

In my experience \x15 is not a character but an FM function (see https://www.daube.ch/docu/files/compendium.pdf#page=493)

What is your opinion in this dilemma:

1. It is an FM bug not to process \u2011 as non-breaking hyphen
2. No, this is not a bug

[Bob_Niland]

It looks like a connundrum.

U+2011 was adopted in 1993, with FM's first opportunity to address this being 2007 (FM8). People may have since come to rely on the present behavior.

A wider problem might be that not enough fonts populate code point U+2011, for example, Source Serif Pro does not. I can use \x15, and create a variable named:
U+2011 NON-BREAKING HYPHEN
that is defined as \x15, and it works (for print & PDF).

But if I define it to be \u2011, I get "?" for most of the fonts in a current project. If \x15 were automatically translated to a UTF-8 "‑" or even ‑ in HTML workflow, end users could be looking at unexpected results in too many cases.

Even if FM did font fallback (and it does not, today), authors lack full font control in HTML output.

As Klaus points out \x15 is more of a mark-up than a character.
What ideally might have happened is that W3C could have defined a named Entity hyphen equivalent of  , perhaps &nbndash;, but they didn't. How does \x11 export to HTML, by the way?

[K.Daube]

«How does \x11 export to HTML, by the way?»

As Spaky wrote to me, it issues an ordinary hyphen, at which the line is broken.

[Bob_Niland]

\x11 is an FM non-breaking space, so I'm not understanding "issues an ordinary hyphen"

I'd expect it to be possibly issued as a Unicode
U+00A0 NO-BREAK SPACE,
and in HTML, as Entity  

[Bob_Niland]

To perhaps answer my own question, it appears that Ctrl+Space (\x11) gets rendered to {Basic} HTML as an ordinary U+0020 space, not as U+00A0,  , nor with CSS applied to the adjacent text for whitespace: nowrap.

[K.Daube]

The behaviour of FM-15 and FM-16 is not at all consistent. I issued a bug report