bugGNU troff - Bugs: bug #59892, translating defined glyphs:...

 
 

bug #59892: translating defined glyphs: undocumented limitations

Submitted by:  Dave <barx>
Submitted on:  Sun 17 Jan 2021 03:40:54 AM UTC  
 
Category:  Core Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 17 Jan 2021 03:40:54 AM UTC, original submission:  

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.

Dave <barx>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by barx (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.6