well -> as well

(preview failure)

Discussion of bug #62923 has revealed a particularly painful gap in our documentary lexicon.

In that ticket an exploration of the relevant issues is forcing us to distinguish "text" special characters from "special" special characters.

This is a terrible state of affairs.

The "special font" concept arises from the glyph repertoire of the Graphic Systems C/A/T delivered to the Bell Labs CSRC circa 1973.  groff_char(7) has some history and background on this.

Whereas text fonts were available in multiple styles like roman, italic, and bold; the special font was not.  At the same time, the special font lacked most characters that were useful for workaday typesetting of English prose, or indeed text in any language.  (In principle, you could perhaps typeset classical Greek using it with a text font for some capital homoglyphs of Latin letters, but this could get weird since the capital Greek letters were always upright and the lowercase ones always slanted.  It seems unlikely that AT&T troff of this vintage was ever seriously turned to such a purpose.)

Back in those simple days with one (typesetter) output device and one set of fonts, the sets of characters that did not have multiple styles available and those from the (one) special font were nearly identical.

There were a few exceptions.  The plus, minus, and equals signs were available in text fonts as well as the special font.  (The reason for this was to reduce the number of font changes, a mechanical process with the C/A/T, when typesetting equations.)

So a careful document author would input the `+`, `\-`, and `=` characters if they wanted "stylable" plus, minus, and equals signs, and `\(pl`, `\(mi`, and `\(eq` if they didn't.  (I suppose eqn(1) was careful to only emit the latter, but I haven't checked this.)

As the years went by, different text fonts became available; font foundries became more friendly to the ASCII character set and sometimes went beyond it even in text typefaces supplied in multiple styles.

groff therefore acquired some additional special characters to represent these stylable text forms to obtain glyphs formerly available only as unstyled glyphs from the "special" font.

\[tno] (not sign), \[t+-] (plus-minus), \[tmu] (multiplication sign), \[tdi] (division sign)

Not entirely consistently, groff also assigned styled glyph semantics to the AT&T troff unstyled special character `\(sr`; it might have been more consistent to introduce a \[tsr] special character for this purpose.  (And we still could.)

(The square root or radical extension glyph situation was a different problem, discussed at length in groff_char(7) in groff git HEAD.)

Conceivably, any old damn glyph could be thrown into a text face and give groff a bigger headache--in principle, we'd need to extend the groff glyph list to accommodate both "text" and "special" (unstyled) variants of what were formerly only "special" (unstyled) glyphs.  Fortunately, there are brakes on such innovation: first, the Unicode Standard is driving the industry toward uniformity by assigning categories like "Letter" to code points and indeed entire blocks of the code space.  Second, it's more work for font designers to develop a glyph in four faces than one.  Third, if a reader can't distinguish a glyph's upright form from its bold or italic styling, there's no point making the distinction in the first place.  (The many styles of dingbat stars are a well-known challenge to designers of low resolution character cell fonts for terminal emulators, but glyphs consisting only of horizontal strokes, like the dash, minus, or equals sign, are also good examples, because they are indistinguishable in their roman and italic styles.)

I propose that our documentation face these difficulties head-on by adopting the categories of "styled glyphs" and "unstyled glyphs".  There will remain a coupling, albeit an imperfect one, between these and "text fonts" contra "special fonts".

I want to try to sort this mess out in clear language.

Whether a character is "ordinary" or "special" determines how you spell it in the input.  An ordinary one represents itself, like "A".  A special character requires an escape sequence for input.

Whether a glyph is styled or unstyled depends on whether it is available in multiple typefaces from the same font family.  A styled glyph is available in roman, italic, bold, and bold-italic.  An unstyled glyph has only one appearance.  (Not quite true; any number of special fonts may be available for the output device, and there is no reason to suppose that their glyph coverage will be disjunct.  See the next item.  Furthermore, since special fonts don't have to be "mounted" to be used, I have no idea what the resolution order for searching the special fonts is.  I think this might make a real difference for the "dvi" output device, whose special font situation is particularly complex.)

Whether a glyph is "text" or "special" depends on where it is found when it is looked up.  If it is found in the currently selected text font (if any[1]), it is a text glyph--otherwise, it is sought in all of the special fonts until located (or lookup fails, whereupon the output driver emits a diagnostic).

The task is to find a way to present the foregoing information clearly.

[1] A text font need not be currently selected at all.

$ groff
.tm \n(.f
1
.ft S
.tm \n(.f
11

I suppose this might be useful if you wanted to force bypass of text fonts to be sure you obtained a(n unstyled) glyph from a special font.  This does seem to be used on rare occasions in groff's own code base.

$ git grep '\\f\[\?S'
tmac/Xps.tmac:.Xps-char \[bu] \f[S]\[bu]
tmac/Xps.tmac:.Xps-char \[f/] \f[S]\[f/]
tmac/Xps.tmac:.Xps-char \[Fn] \f[S]\[Fn]
tmac/psold.tmac:.char \[de] \fS\(de

(There were no matches for use of "ft S".)

This technique could of course also be used to ensure that you got a glyph from a specific special font, like devlj4's "WINGDINGS" font--though, oddly, that font's own description file does not include the "special" keyword, so I don't know what's going on there.

This concludes my brain dump.