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

 
 

bug #59892: translating defined glyphs: undocumented limitations

Submitter:  Dave <barx>
Submitted:  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
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 18 Apr 2022 07:16:00 AM UTC, comment #1: 

That link to the email thread is broken; try http://lists.gnu.org/r/groff/2020-07/msg00019.html instead.

Dave <barx>
Group Member
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>
Group 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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code