[Groff] space and \~ in .tr request

[Werner LEMBERG]

My current work on groff is to allow `\~' in the `.tr' request (only
as a character to be mapped to):

  .tr \[char160]\~

This is needed e.g. to implement full latin-1 input encoding support
which has a non-breakable space.

The similar request, as you all know,

  .tr \[xxx]

maps the character `xxx' onto the space character, or rather, it maps
onto `\ ', i.e., an unpaddable, unbreakable space character. (Can
someone please check this with AT&T troff?)  BTW, a real bug is that
hyphenation (both implicit and explicit) doesn't work before the
mapped space.  The original troff documentation says (in section
10.5):

  All text processing takes place with the input character which
  appears to have the width of the final character.

But is this the ideal solution for a space character?

I would like to change groff's `.tr' implementation so that mapping a
character onto a space is either a) or b):

  a) an unpaddable, breakable space character
  b) a paddable, breakable space character

My favor is b).  Please tell me whether you have ever used mapping
onto a space and which solution you prefer.  groff will of course
emulate the original troff behaviour (whatever it is) while in
compatibility mode.  I would also add `\ ' to the .tr request in case
b) appears to be the right choice.

Regardless which solution will be implemented for the space character,
`\~' in `.tr' will yield a paddable, unbreakable space.


    Werner