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.

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.