[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #59892] translating defined glyphs: undocumented limitations
From: |
Dave |
Subject: |
[bug #59892] translating defined glyphs: undocumented limitations |
Date: |
Sat, 16 Jan 2021 22:40:56 -0500 (EST) |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0 |
URL:
<https://savannah.gnu.org/bugs/?59892>
Summary: translating defined glyphs: undocumented limitations
Project: GNU troff
Submitted by: barx
Submitted on: Sat 16 Jan 2021 09:40:54 PM CST
Category: Core
Severity: 3 - Normal
Item Group: Incorrect behaviour
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: None
_______________________________________________________
Details:
This bug report is a distillation of the thread at
http://lists.gnu.org:443/archive/html/groff/2020-07/msg00019.html. I ended up
using a different technique to meet my needs so have done no further
investigation.
== The problem ==
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).
== Analysis ==
Tadziu posited that defining c in terms of itself created a (non-terminating)
recursive mapping, observing that with another character it works:
.tr k\[red-c]o\[slashed-o]
bock
It also works if you define "red-c" not in terms of "c", but the character
encoding number:
.char \[red-c] \m[red]\N'99'\m[]
bock
But infinite recursion alone does not explain this, because these definitions
ought to have the same problem:
.char a dab
.tr ba
bag
But this outputs "daadaag" with no errors or warnings. And you can surround
the target of this .char definition with \m escapes and it still works fine.
The following also works:
.char a \m[red]a\m[]
.char b \m[blue]b\m[]
.tr abba
ab
and prints a red "b" and a blue "a". So I'm not sure precisely what the
limitation is. It seems best to fix it so there is no such limitation, but if
that's too intractable, it should be documented.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?59892>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [bug #59892] translating defined glyphs: undocumented limitations,
Dave <=