bugGNU roff - Bugs: bug #62973, introduce documentary concept:...


bug #62973: introduce documentary concept: "unstyled" characters/glyphs

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Sun 28 Aug 2022 04:02:31 PM UTC
Category:  Core Severity:  1 - Wish
Item Group:  Documentation Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup

Wed 07 Jun 2023 11:41:16 PM UTC, comment #4: 

commit 294b7a71ca116a5fec94fee491ea20b42a9aa976
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Tue Jun 6 08:37:35 2023 -0500

    ChangeLog: Add bug closers for recent doc fixes.

G. Branden Robinson <gbranden>
Group administrator
Mon 05 Jun 2023 06:13:05 AM UTC, comment #3: 

I did it.  It needs a ChangeLog bug-closer.

commit 890c9e30b8d468a4ddd228da516f08fb76ae074e
Author:     G. Branden Robinson <g.branden.robinson@gmail.com>
AuthorDate: Mon May 29 10:33:19 2023 -0500
Commit:     G. Branden Robinson <g.branden.robinson@gmail.com>
CommitDate: Mon May 29 10:33:19 2023 -0500

    [docs]: Revise discussion of fonts.

    * doc/groff.texi:
      -  Rename node/section "Fonts and Symbols" to "Using Fonts".  Add
         giant new introduction, properly establishing terminology.
      -  Rename node/section "Changing Fonts" to "Selecting Fonts".  Shift
         location of `.fn` and `.sty` register documentation.  Rewrite
         presentation of `ft` and `\f`.  Discuss typeface selection by
         mounting position and font (or style) name together; since
         arguments to these formatter instructions are always interpreted as
         mounting positions first, it doesn't make much sense to me to
         present them separately, and the new introduction provides the
         necessary background.  Tighten example.  Document that current and
         previous font selections are environment properties.
      -  Add several concept index entries.
      -  Do more migration from "symbol" and "glyph" names to "special
         character" names.

    * man/groff.7 (Using fonts): Introduce new section, synced with the
      renamed node from our Texinfo manual above.

G. Branden Robinson <gbranden>
Group administrator
Fri 02 Sep 2022 11:07:47 PM UTC, comment #2: 

well -> as well

(preview failure)

G. Branden Robinson <gbranden>
Group administrator
Fri 02 Sep 2022 11:07:19 PM UTC, comment #1: 

> here 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.)

It would be better to phrase this a bit the other way around.

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

G. Branden Robinson <gbranden>
Group administrator
Sun 28 Aug 2022 04:02:31 PM UTC, original submission:  

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
.ft S
.tm \n(.f

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.

G. Branden Robinson <gbranden>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

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 (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.


    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-06-07 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2023-06-05 gbranden StatusNone In Progress
        Assigned toNone gbranden
        Planned ReleaseNone 1.23.0

    Back to the top

    Powered by Savane 3.13-c373.
    Corresponding source code