bugGNU troff - Bugs: bug #63366, groff.texi: clarify handling of...

 
 

bug #63366: groff.texi: clarify handling of special fonts

Submitter:  Dave <barx>
Submitted:  Mon 14 Nov 2022 05:23:18 PM UTC
 
Category:  Core Severity:  2 - Minor
Item Group:  Documentation Status:  Need Info
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

Mon 21 Nov 2022 09:24:31 AM UTC, comment #3: 

comment #1:

> Now, why this vector of special fonts isn't reported as the
> global_special_fonts list, I don't know.  I'm not certain
> they're supposed to be the same thing.


I'm not either, hence filing this as a documentation bug under the assumption that the code is working right, just not explained well.  (Pre-groff behavior can illuminate only so much, since troff historically lacked a .special request.  CSTR #54 does speak of "one or more special fonts," suggesting there was some mechanism for adding them; perhaps this was a hardware operation.)

Since learning that special fonts are irrelevant to the issue I was trying to understand in bug #63354, my desire to poke more at this now has dwindled, but I'll let the bug report linger until you work your way down to this part of the docs.

Dave <barx>
Project Member
Tue 15 Nov 2022 03:24:16 AM UTC, comment #2: 

Here's my silly patch to aid font debugging.

diff --git a/src/roff/troff/node.cpp b/src/roff/troff/node.cpp
index 96697e076..f2f8d9443 100644
--- a/src/roff/troff/node.cpp
+++ b/src/roff/troff/node.cpp
@@ -170,6 +170,7 @@ public:
   int get_zoom();
   friend symbol get_font_name(int, environment *);
   friend symbol get_style_name(int);
+  friend void print_fonts();
 };

 class tfont_spec {
@@ -6310,6 +6311,26 @@ void special_request()
   skip_line();
 }

+void print_fonts()
+{
+  if (font_table_size > 0) {
+    errprint("font table size: %1\n", font_table_size);
+    errprint("font table:\n");
+    for (int i = 0; i < font_table_size; i++) {
+      font_info *f = font_table[i];
+      if (0 /* nullptr */ != f)
+       errprint("%1: %2\n", i, f->internal_name.contents());
+    }
+  }
+  errprint("global special fonts:\n");
+  special_font_list *sflp = global_special_fonts;
+  while (0 /* nullptr */ != sflp) {
+    errprint("%1\n", sflp->n);
+    sflp = sflp->next;
+  }
+  fflush(stderr);
+}
+
 void font_zoom_request()
 {
   font_lookup_info finfo;
@@ -6634,6 +6655,7 @@ void init_node_requests()
   init_request("ftr", font_translate);
   init_request("kern", kern_request);
   init_request("lg", ligature);
+  init_request("pft", print_fonts);
   init_request("rfschar", remove_font_special_character);
   init_request("shc", set_soft_hyphen_char);
   init_request("special", special_request);

G. Branden Robinson <gbranden>
Project Administrator
Tue 15 Nov 2022 03:23:02 AM UTC, comment #1: 

original submission:

> The "Special Fonts" section of the Texinfo documentation is ambiguous on one point and seemingly missing info on another.
>
> This section was last touched in 2014 (by commit e3c63595, fixing a recurring grammatical nit throughout the file), so has remained unchanged since 1.22.3 (and therefore hasn't been Brandenified).


Hi Dave,

Yes, I haven't yet revised our Texinfo manual in the "fonts and symbols" department because it's going to take some significant effort to reform.  Also there are many points of detail that I need to learn and confirm.

> This section says both "The Symbol font is usually a special font" and "Use the 'special' request to define special fonts.  Initially, this list is empty."  So the initial list of special fonts both is empty and contains Symbol.


There is a data structure in GNU troff's node.cpp called "global_special_fonts" that is presumably the list that this refers to, and this is indeed empty on startup.  (I quickly implemented a `pft` request to dump some font state to stderr.)
fonts 9 0 0 0 0 0 SS S ZD ZDR
".special BOGUS" produces a diagnostic now (as we already knew from earlier this year), but more tellingly (for the "ps" device) ".special TR" does indeed add Times Roman to this formerly empty list, and ".special" with no arguments does clear it out again.

> That Symbol is in fact a default special font is easily demonstrable.  The groff input characters \[HE] and \[CL] have glyphs in Symbol but not Times:

> $ egrep 'HE|CL' /usr/share/groff/current/font/devps/TR
> $ egrep 'HE|CL' /usr/share/groff/current/font/devps/S
> CL      753,533,26      3       167     club
> HE      753,532,33      3       169     heart

> And groff input that specifies no font information, defaulting to Times, also finds Symbol when needed:

> $ printf 'I \[HE] my \[CL]\n' | groff -Z | fgrep font
> x font 5 TR
> wx font 11 S


I think something else is going on here.  Our documentation also says this:

"special
              The font is special: when a glyph is requested that is not present in the current font, it is sought in any mounted fonts that bear               this property."

...and when we consult the 'ps' device's DESC file, we see the line

fonts 9 0 0 0 0 0 SS S ZD ZDR

...which means that the Symbol font is mounted.  (In fact, all of these named fonts are special.)

Now, why this vector of special fonts isn't reported as the global_special_fonts list, I don't know.  I'm not certain they're supposed to be the same thing.

(There might be some C++ variable scoping issues.  global_special_fonts is local to the node.cpp file, but DESC file parsing and the actions that are taken consequent to the directives found there happen in libgroff.)

> This section of the manual also states, "Previous calls to 'special' or 'fspecial' are overwritten; without arguments, the particular list of special fonts is set to empty."  So to remove the Symbol font from the list of special fonts, one ought to be able to give these requests empty lists.


This statement seems to accurately describe the way the requests are implemented.

> But this doesn't behave as might be expected from the above-quoted sentence:

> $ printf '.special\n.fspecial TR\nI \[HE] my \[CL]\n' | groff -Z | fgrep font
> x font 5 TR
> wx font 11 S

> That the two ".*special" requests in this sample input are essentially no-ops can be explicitly demonstrated via:

> $ diff <(printf 'I \[HE] my \[CL]\n' | groff -Z) <(printf '.special\n.fspecial TR\nI \[HE] my \[CL]\n' | groff -Z) | wc
>       0       0       0

> I can only conclude that the Symbol font is an extra-special special font that exists outside the ordinary "special" mechanism.  The documentation could be clearer about this.
>
> Additionally, I'm puzzled by the word "usually" up there.  How does one overturn this usual case, if the documented method of emptying the lists of special fonts exempts the extra-special Symbol font?


If there were a way to un-mount a font...well, actually there is.

Try your experiments after doing this.

.fp 11 TR

This will clobber the "S" font's slot in the table with a copy of Times Roman.  This is an ugly hack, but I suspect it will work.

I imagine that the problem here is a bug: the `global_special_fonts` variable in troff is not wired up to the outcome of DESC file processing as it should be.  You might ask on the list; it seems to be the season for the oldsters to wearily sigh and attempt to correct the wayward youths.

Font and particularly character/glyph resolution are pretty complex in groff and I have not mastered the details; probably the only way that will happen is if I undertake that documentation revision.

But we should be prepared to reclassify this as yet another decades-old bug.

G. Branden Robinson <gbranden>
Project Administrator
Mon 14 Nov 2022 05:23:18 PM UTC, original submission:  

The "Special Fonts" section of the Texinfo documentation is ambiguous on one point and seemingly missing info on another.

This section was last touched in 2014 (by commit e3c63595, fixing a recurring grammatical nit throughout the file), so has remained unchanged since 1.22.3 (and therefore hasn't been Brandenified).

This section says both "The Symbol font is usually a special font" and "Use the 'special' request to define special fonts.  Initially, this list is empty."  So the initial list of special fonts both is empty and contains Symbol.

That Symbol is in fact a default special font is easily demonstrable.  The groff input characters \[HE] and \[CL] have glyphs in Symbol but not Times:

$ egrep 'HE|CL' /usr/share/groff/current/font/devps/TR
$ egrep 'HE|CL' /usr/share/groff/current/font/devps/S
CL      753,533,26      3       167     club
HE      753,532,33      3       169     heart

And groff input that specifies no font information, defaulting to Times, also finds Symbol when needed:

$ printf 'I \[HE] my \[CL]\n' | groff -Z | fgrep font
x font 5 TR
wx font 11 S

This section of the manual also states, "Previous calls to 'special' or 'fspecial' are overwritten; without arguments, the particular list of special fonts is set to empty."  So to remove the Symbol font from the list of special fonts, one ought to be able to give these requests empty lists.

But this doesn't behave as might be expected from the above-quoted sentence:

$ printf '.special\n.fspecial TR\nI \[HE] my \[CL]\n' | groff -Z | fgrep font
x font 5 TR
wx font 11 S

That the two ".*special" requests in this sample input are essentially no-ops can be explicitly demonstrated via:

$ diff <(printf 'I \[HE] my \[CL]\n' | groff -Z) <(printf '.special\n.fspecial TR\nI \[HE] my \[CL]\n' | groff -Z) | wc
      0       0       0

I can only conclude that the Symbol font is an extra-special special font that exists outside the ordinary "special" mechanism.  The documentation could be clearer about this.

Additionally, I'm puzzled by the word "usually" up there.  How does one overturn this usual case, if the documented method of emptying the lists of special fonts exempts the extra-special Symbol font?

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 gbranden (Posted a comment)
  • -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.

     

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-11-15 gbranden StatusNone Need Info

    Back to the top

    Powered by Savane 3.9