Re: [groff] 04/28: groff_char(7): Revise glyph descriptions.

[G. Branden Robinson]

Hi folks,

Ingo sent me some private feedback about the commit in the Subject:,
but I don't know if he meant for it to be private, and I wanted to
solicit opinions from the team about the points he raised, especially
since one of them might be usefully addressed by someone with knowledge
of the historical origins of "text variants" and "special font" forms of
a handful of mathematical operators.

In the event he did intend to reply privately, I've replaced Ingo's words
with my own bracketed summaries thereof.

***

[...]

Hi, Ingo.  It was even more work than I expected! :-O

[...]

Thank you for your review.  Did you mean to send this privately?  Feel
free to copy my replies to the groff list.

[curly braces]

> True.  Then again, given how many different enclosures exist, i found
> the "curly" helpful, even if it may have been redundant, and it didn't
> overflow the line.

I'm not strongly opposed.  I had a pass over the glyph descriptions
where I grabbed every economy I could.  (And then practically wept at
adding "indicator" to "{femin,mascul}ine ordinal"...)

> >       + Say "special variant of" instead of "in special font", so
> >       that the parallelism with "text variant of" is clear.

[dislikes this wording]

It was difficult to come up with a solution here and I'm not thrilled
with the one I chose.  These cases are the only ones where the font
mounting is implicit in the semantics of the glyph name instead of left
to the author of the postprocessor description files.  \[t{mu,di,+-}]
must be groff innovations, judging by the name lengths.

I'm attaching some images from CSTR #54 1976 and Kernighan's "A TROFF
Tutorial" that may help elucidate the issue.  CSTR #54 itself, in
neither revision, seems to allude to this issue, but Kernighan does in
his tutorial.

> > -\[char223] \[char223] 223 germandbls u00DF German double s (sharp s)
> > +\[char223] \[char223] 223 germandbls u00DF lowercase sharp s

[there is no uppercase Eszett]

Au contraire!  It's U+1E9E, added in Unicode 5.0.[1]

[...]

Yes, and as I understand it, \(ss originates as a ligature of "sz"
anyway, further underscoring the wrongness of "double s".

I took two years of the German language in a U.S. high school, so I know
a little, but not enough to communicate grammatically, or with a
vocabulary that reaches even the lowest standards of adequacy.

> > -\[sq]      \e[sq]  uni25A1 u25A1   white square +
> > +\[sq]      \e[sq]  uni25A1 u25A1   square +

[this loses information]

I wanted to say "outline" or something, and faced a similar issue with
the "circle", which is at least strictly correct.  "Square" is, too; I
suppose "block" describes a filled rectangle (and Unicode uses this for
many of its semigraphics code points, e.g., U+2580-U+2590).

But we're screwed either way because if you set \[sq] in a bold font it
becomes filled.  :-|  See attachments.

Unicode has gone some distance to disambiguate this stuff, and it no
longer seems to be current practice (see roff attachment).  Perhaps we
can make changes.

> > -\[pl]      \e[pl]  plus    u002B   plus in special font +
> > -\[mi]      \e[mi]  minus   u2212   minus in special font +
> > +\[pl]      \e[pl]  plus    u002B   special variant of plus +
> > +\[mi]      \e[mi]  minus   u2212   special variant of minus +
> > -\[eq]      \e[eq]  equal   u003D   equals in special font +
> > +\[eq]      \e[eq]  equal   u003D   special variant of equals +

[should we really get rid of the word "font" in these strange cases]

This continues the earlier point.  To answer your question, no, I'm not
sure.  These feel like warts in the glyph namespace to me, and 40+ years
after the Graphical Systems C/A/T, I don't think any producer of digital
fonts dares omit any ISO 646 code points from an alphanumeric font
anymore.

But there may be more to the story than that; as we can see from the
attachments, plus, minus, and equals were right there in Times all
along even when other ASCII punctuation (like #) was not.  I have a
suspicion that these characters were duplicated into font-specific
variants because they were commonly used in both mathematical and
non-mathematical contexts, and the people at Bell Labs wanted a way to
economize keystrokes without pushing and popping font escapes, and also
to avoid unnecessary rotations of the font mounting wheel in the
typesetter, which would take time and cause mechanical wear.

That's what I think all this is--a domain-specific optimization that has
long since lost its foundation.

> > -\[Fn]  \e[Fn]  florin  u0192   Dutch currency sign

[line deleted without replacement]

I did do it on purpose but this change was wrongly included in this
commit, an error I made while rebasing.  It should have appeared in
the next commit:

        commit b09117611f03b8345ba907f16972a1a99a81f155
        Author: G. Branden Robinson <g.branden.robinson@gmail.com>
        Date:   Thu Aug 27 20:29:12 2020 +1000

            groff_char(7): Alter code tables.
[...]
            * Rename "Dutch currency sign" to "lowercase f with hook"
              and move from "Currency symbols" to "Supplementary Latin
              letters".  The florin is presently of historical rather
              than commercial interest, and lacks the "Currency"
              attribute in Unicode, which is suggestive.  This also
              internationalizes (as opposed to localizing) the
              description.  Add "function" to its description.

Sorry about that.

Regards,
Branden

[1] https://www.unicode.org/charts/PDF/U1E00.pdf

CSTR_54_1976_font_examples_1_of_2.png
Description: PNG image

CSTR_54_1976_font_examples_2_of_2.png
Description: PNG image

kernighan_troff_tutorial_phototypesetter_character_set_1_of_2.png
Description: PNG image

kernighan_troff_tutorial_phototypesetter_character_set_2_of_2.png
Description: PNG image

roman-bold-square.roff
Description: Troff document

signature.asc
Description: PGP signature