[bug #65710] [preconv] require disambiguation of U+00A0 on input

[Dave]

Follow-up Comment #1, bug #65710 (group groff):

[comment #0 original submission:]
> an input U+00A0...: is it a fixed-width non-breakable space, or a
> variable-width non-breakable space?  Unicode does not distinguish.

Unicode intentionally provides some latitude to rendering engines to make the
best typographical decisions they can.  That is, Unicode is not really a
driving factor here; the only Unicode requirement of U+00A0 is that it be
nonbreaking, and both "\ " and "\~" meet that requirement.

Since 2003 ([http://git.savannah.gnu.org/cgit/groff.git/commit/?id=48615a44
commit 48615a44]), groff_char(7) has said "the ISO Latin-1 no-break space is
mapped to `\~', the stretchable space character."  While this claim was
erroneous until bug #58962 addressed it (and remains erroneous with certain
fonts, per bug #65693), it has always been the most typographically sound
solution.

I think groff should strive to do by default what makes most typographic
sense, and (as #58962 argued) there are few if any situations where "\ " is
preferable to "\~".

> This is analogous to how we don't know whether a man page
> author means a hyphen or a minus sign when they type `-`.

Weakly analogous:
* Hyphens and minus signs are different semantically.  The two types of
nonbreaking spaces are different only presentationally.
* Hyphens and minus signs must copy to the clipboard as different characters;
both types of nonbreaking spaces will possibly copy as U+00A0, though more
probably (and more usefully to the user in most cases) copy as an ordinary
space.

> 2.  Add an option instructing preconv which escape sequence to
> transform U+00A0 into.

I don't oppose an option to _override_ the default escape preconv uses, but
its current default is sound.  (Still, I would question the need for such an
option, since users can always specify either escape directly in the source,
and preconv won't touch it.)


    _______________________________________________________

Reply to this item at:

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

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