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

Follow-up Comment #16, bug #55154 (group groff): But zooming out: Comment #13 was my attempt to test my hypothesis of "why .char doesn't work for this" as presented in comment #11. This is all tangential to the purpose of this ticket, which covers the .tr request and various types of spaces.

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

Follow-up Comment #15, bug #55154 (group groff): [comment #14 comment #14:] > Try this patch: Just tried to apply it, but it appears to have already been committed as [http://git.savannah.gnu.org/cgit/groff.git/commit/?id=84bf4520b commit 84bf4520b].

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

Update of bug #55154 (group groff): Assigned to:None => barx ___ Follow-up Comment #14: Try this patch: diff --git a/src/roff/troff/node.cpp b/src/roff/troff/node.cpp index

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

Follow-up Comment #13, bug #55154 (group groff): [comment #11 comment #11:] > I presume this is due to this explanation in the Texinfo manual: > > -- Request: .char c ['"'][contents] > Every time C is to be output, CONTENTS is processed in a > temporary environment and the result

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

Follow-up Comment #12, bug #55154 (group groff): [comment #11 comment #11:] > While everything here appears to be working as designed, I'm > tempted to open a new bug report anyway, Succumbed to temptation: bug #65829 ___ Reply to this

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

Follow-up Comment #11, bug #55154 (group groff): [comment #10 comment #10:] > Bizarrely, while it accepts the second translation, it doesn't > actually honor it. It gets worse: even .char fails at this. $ cat char-test .char b \~ abc cba\p $ nroff char-test | cat -s a c

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

Follow-up Comment #10, bug #55154 (group groff): [comment #0 original submission:] > .tr a > .tr b\~ > .tr c\ > .tr d\| > .tr e\^ > .tr f\0 > > This attempts to translate six alphabetic characters to six > different types of space characters. What it does instead is > accept the first two

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

Follow-up Comment #9, bug#55154 (group groff): [comment #7 comment #7:] > > I don't think \| and \^ are too much of a challenge here. > > I recall you've spoken about the font file's ability to alter > their sizes being a feature you've never seen used in practice, > and maybe floated the idea

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

Follow-up Comment #8, bug #55154 (project groff): Everything else I wanted to say (here and in bug #64337) I ended up talking myself out of. All I have left are two minor comments on the documentation update. [comment #6 comment #6:] > > This feature replaces the odd-parity tr mapping trick

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

Follow-up Comment #7, bug #55154 (project groff): [comment #6 comment #6:] > Possibly, we should try deprecating both of these uses of `tr`, > so that we can say simply that `tr` remaps *characters* (ordinary > or special). Full stop. Now that this proposal has its own ticket (bug #64337), I'll

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

Follow-up Comment #6, bug #55154 (project groff): I may be groping toward an apology (in the formal, rhetorical, not conversational, sense) in the course of recent plus pending changes to groff_diff(7). I had forgotten, and thus was semi-surprised, that ".tr a\ " (note trailing space) was not

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

Follow-up Comment #5, bug #55154 (project groff): A subset of escape sequences interpolates special characters. \` \' \- \_ \(xx \[xxx] No escape sequences interpolate ordinary characters. (I'm ignoring \*(xx and \*[xxx], which interpolate strings potentially containing characters.)

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

Follow-up Comment #4, bug #55154 (project groff): I also wonder whether this statement in groff.texi should be expanded: "The following characters can't be translated: space (with one exception, see below), backspace, newline, leader (and '\a'), tab (and '\t')." It is not just ordinary space

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

Follow-up Comment #3, bug #55154 (project groff): Yes, that makes sense; the documentation changes you speak of (commit bf6ff8f2 ) refute my "illogically inconsistent" claim in the initial report.

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

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

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

Update of bug #55154 (project groff): Summary: .tr has undocumented and inconsistennt space-character restrictions => .tr has undocumented and inconsistent space-character restrictions ___ Reply to this item at: