[bug #63354] Refine fallbacks.tmac

[Dave]

Follow-up Comment #41, bug #63354 (group groff):

[comment #40 comment #40:]
> I suggest that it doesn't.

Hence "arguably."

> That caveat seems to hoist on us on the very petard that
> separates the marauding `\:` Turk from the `\&` ground soaked
> by the bloodthirsty Romanians.

I don't think a case can be made for \&.  That doesn't permit a break, and I
hope if we can agree on nothing else, we can agree that a character named
"BREAK PERMITTED HERE" ought to permit a break.

So the only reasonable choices are \: or \%--each permitting a break, one
adding a hyphen if a break occurs there, one not.

The Unicode standard v15.1 is light--to the point of malfeasance--on the
meanings of most characters in the C1 control block. 
(http://www.unicode.org/charts/PDF/U0080.pdf)  The Unicoderati, it seems,
would rather you avoid these legacy code points altogether and use their
newer, more well-defined counterparts.  And that's the advice I'd give to
anyone composing new Unicode text.

But what _of_ legacy documents?  This is an area where groff ought to shine. 
And what the Unicode standard is furtive about, we can deduce from the content
of the overall C1 Controls and Latin-1 Supplement block.

Specifically, this block contains the character U+00AD SOFT HYPHEN, the
function of which Unicode is more forthcoming about: "an invisible format
character indicating a possible hyphenation location".  This, in roffese, is
\%.

So why would another character in the same block also translate to \%?  It
seems clear the original intent of U+0082 BREAK PERMITTED HERE is to define a
potential break point that _doesn't_ get hyphenated--the \:, in roffese.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63354>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

signature.asc
Description: PGP signature