[bug #63194] [ec.tmac] doesn't play well with man(7) font remapping

[G. Branden Robinson]

URL:
  <https://savannah.gnu.org/bugs/?63194>

                 Summary: [ec.tmac] doesn't play well with man(7) font
remapping
                 Project: GNU troff
               Submitter: gbranden
               Submitted: Mon 10 Oct 2022 03:50:50 PM UTC
                Category: Font - others/general
                Severity: 3 - Normal
              Item Group: Warning/Suspicious behaviour
                  Status: In Progress
                 Privacy: Public
             Assigned to: gbranden
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Mon 10 Oct 2022 03:50:50 PM UTC By: G. Branden Robinson <gbranden>
Our _an.tmac_ file performs some font remapping tricks that it didn't used to
in groff 1.22.4.

This doesn't work well with a few of the font (really, style) remapping
attempts in ec.tmac.


$ ./build/test-groff -b -ww -mec -mandoc -Tdvi dvi-ec.man >| dvi-ec.dvi 
troff: backtrace: file 'dvi-ec.man':6
troff:dvi-ec.man:6: warning: cannot select font 'I'


Let's have a look at that input file.


$ cat dvi-ec.man 
.TH foo 1 2022-10-10 "groff test suite"
.SH N\['E]V \f[BI]groff\f[] \fBGNU\fP
.\" The per mille sign is available only in the EC fonts, so if we
.\" failed to switch them in, we'll get an undefined special character
.\" warning.
foo \- \[%0]\fIgroff


Notice that neither of the font changes in the .SH call get complained about. 
`SH` itself does some remapping these days. Italics in a heading get mapped to
bold italics to keep the font weight consistent.

`SH` politely backs out its remappings afterward, but it doesn't save where
they went in the first place, on the assumption that no one was doing any
remapping.  As far as I know, this information is also impossible to obtain
from within the language.  There's no request or escape sequence to inquire
whither a typeface identifier is remapped.

On the bright side, some of the stuff ec.tmac is doing doesn't even seem to be
necessary.  I disabled a bit of it to see.


$ git diff
diff --git a/tmac/ec.tmac b/tmac/ec.tmac
index 7f37ddfc6..d3f45ee03 100644
--- a/tmac/ec.tmac
+++ b/tmac/ec.tmac
@@ -12,6 +12,7 @@
 .do nr *groff_ec_tmac_C \n[.cp]
 .cp 0
 .
+.ig
 .ftr R REC
 .ftr I IEC
 .ftr B BEC
@@ -21,6 +22,7 @@
 .sty 2 B
 .sty 3 I
 .sty 4 BI
+..
 .
 .ftr CW CWEC
 .ftr CWI CWIEC


Then re-ran the failing command, and got no diagnostics.


$ ./build/test-groff -bz -ww -mec -mandoc -Tdvi dvi-ec.man >| dvi-ec.dvi 2>&1
| grep . || echo no error output
no error output


But does commenting that out screw up real documents for the DVI device?

Well, I checked, by rendering the grodvi man page, which renders samples of
all its own text fonts.  And things seem fine.  I'll attach it.

The test exhibit, mind you, _does_ complain if you leave out the -mec
argument, because the per mille sign is unavailable in the CM fonts--so we get
an error we expect.


$ ./build/test-groff -bz -ww -mandoc -Tdvi dvi-ec.man >| dvi-ec.dvi
troff: backtrace: file 'dvi-ec.man':6
troff:dvi-ec.man:6: warning: special character '%0' not defined


So I'll proceed with this.







    _______________________________________________________
File Attachments:


-------------------------------------------------------
Date: Mon 10 Oct 2022 03:50:50 PM UTC  Name: grodvi.dvi  Size: 11KiB   By:
gbranden

<http://savannah.gnu.org/bugs/download.php?file_id=53829>

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63194>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/