> And I can surround the target of this .char definition
> with \m escapes and it still works fine. So something
> else seems to be going on here.
You are right -- it's not that simple. For example,
the following also works:
.char a \m[red]a\m[]
.char b \m[blue]b\m[]
.tr abba
ab
and
Hi Dave and Tadziu,
At 2020-07-17T10:58:40+0200, Tadziu Hoffmann wrote:
>
> > .char \[red-c] \m[red]c\m[]
> > .char \[slashed-o] \[/o]
> > red-c is \[red-c]; slashed-o is \[slashed-o]
> > .br
> > .tr c\[red-c]o\[slashed-o]
> > bock
> >
> > Of these two new glyphs defined with .char, .tr only
> >
On 7/17/20, Tadziu Hoffmann wrote:
> It may be because you're defining c in terms of itself,
> so you get a (non-terminating) recursive mapping.
Hmm, curious, because it doesn't seem to hold in the general case.
These definitions ought to have the same problem:
.char a dab
.tr ba
bag
But this o
> .char \[red-c] \m[red]c\m[]
> .char \[slashed-o] \[/o]
> red-c is \[red-c]; slashed-o is \[slashed-o]
> .br
> .tr c\[red-c]o\[slashed-o]
> bock
>
> Of these two new glyphs defined with .char, .tr only
> recognizes \[slashed-o]. The other generates the warning
> "7: warning: can't find special
In the section about .char, groff's info manual says: "A glyph defined by [this
request] can be used just like a normal glyph provided by the output device.
In particular, other characters can be translated to it with the 'tr' or 'trin'
requests..." This statement is reiterated in the section
