[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
translating defined glyphs: docs vs reality
From: |
Dave Kemper |
Subject: |
translating defined glyphs: docs vs reality |
Date: |
Fri, 17 Jul 2020 03:14:52 -0500 |
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 on .tr: "glyphs
defined with the 'char' request... can be translated also."
Except it doesn't actually work that way.
.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 character
`red-c'" (even though groff found it just fine when calling it directly via
that name).
.tr seems to only recognize glyphs defined with .char when the new definition
is also only a glyph, even though .char itself is perfectly happy to accept
other escapes as part of the new glyph. The manual gives no hint of this
limitation.
Is the documentation wrong (or at least incomplete)? Or is groff's behavior
wrong?
- translating defined glyphs: docs vs reality,
Dave Kemper <=