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

[G. Branden Robinson]

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

                 Summary: introduce documentary concept: "unstyled"
characters/glyphs
                 Project: GNU troff
               Submitter: gbranden
               Submitted: Sun 28 Aug 2022 04:02:31 PM UTC
                Category: Core
                Severity: 1 - Wish
              Item Group: Documentation
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Sun 28 Aug 2022 04:02:31 PM UTC By: G. Branden Robinson <gbranden>
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.







    _______________________________________________________

Reply to this item at:

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

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