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/
