[bug #55154] .tr has undocumented and inconsistent space-character restrictions

[G. Branden Robinson]

Update of bug #55154 (project groff):

                  Status:                    None => Need Info              

    _______________________________________________________

Follow-up Comment #2:

Hi Dave,

With my recent terminological revisions and clearer distinction between
"spaces" and (horizontal) "motions", this puzzling behavior becomes more
understandable, I think.

Character translation targets have to be input sequences that are constitutive
of text.

That includes spaces, which are discardable and may be breakable or not, but
not _motions_, which are never either.

If we pretend that a font's word space is one en wide, and its numerals 1 em
wide, then the following inputs are equivalent.


.tr c\ \" translate to escaped space
.tr d\|
.tr e\^
.tr f\0

.tr c\h'1n'
.tr d\h'1m/6u'
.tr e\h'1m/12u'
.tr f\h'1m'


No one attempts to translate characters to horizontal or vertical motions, or
crazier things like device control escape sequences.  Thus the acceptance and
rejection pattern you see.

Do you buy this?  If so, I can update the document to make the corresponding
clarfication.


    _______________________________________________________

Reply to this item at:

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

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