[bug #59892] translating defined glyphs: undocumented limitations

[Dave]

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/