Follow-up Comment #3, bug #68252 (group groff): [comment #2 comment #2:] > 10. USG _man_ sets up overstrike-based emboldening of the special font > whenever a glyph from it is needed and the currently selected font mounting > position is "3". Traditionally in *roff, the font "B" (bold) is assigned to > that position.
I didn't squarely address why this point doesn't affect my conclusion.
It has to do with practicalities and esthetics.
Q. Why did USG want to bold the special font when the bold typeface for text
was selected?
A. Because it looks like we're dealing with a Graphic Systems, Inc. (later
Wang) C/A/T output device, thus the output device resolution presumed by the
"runit.sh" script that accompanies another document (from the same project, I
think), which I'll quote because it's extremely short.
# @(#)runit.sh 5.2 of 5/14/82
# The argument to -rW is in basic units and should be:
# -rW2052 for small (-rs1) troff (4.75i * 432)
# -rW2808 for large troff & nroff (6.5i * 432)
mmt -rs1 -rW2052 errmacs errintro
mmt -t -rs1 -rW2052 errmacs errmess?
If one lays eyes on the "Nroff/Troff User's Manual" in the Seventh Edition
Unix Programmer's Manual, Volume 2, one can inspect dumps of the four faces of
the C/A/T's repertoire.
Let me quote _groff_char_(7):
At the time Graphic Systems delivered the C/A/T phototypesetter to
AT&T, the ASCII character set was not considered a standard basis
for a glyph repertoire by traditional typographers. In the stock
Times roman, italic, and bold styles available, several ASCII
characters were not present at all, nor was most of the Teletype’s
extended character set. AT&T commissioned a “special” font to
retain their accustomed repertoire.
...
The special font supplied the missing ASCII and Teletype extended
glyphs, among several others. The plus, minus, and equals signs
appeared in the special font despite availability in text fonts “to
insulate the appearance of equations from the choice of standard
[read: text] fonts”——a priority since troff was turned to the task
of mathematical typesetting as soon as it was developed.
The `bd` request was present to avoid an inconsistency in stroke weight when
formatting a glyph from the "special" font ("S") in a "text" context.
That's well and good and, I imagine, esthetically correct. I have no
complaint about it (despite the problems that the `bd` request has given me
and other _groff_ developers--see bug #64166 and bug #64866 😛).
**BUT**
Modern typesetting environments emphatically do not use the C/A/T's fonts,
which didn't even exist in the digital domain. They appeared only on
photographic film and rendering them used lenses, flash bulbs, wet paper and
processes unfamiliar to those of us spoiled by laser printers.
If one wants an authentic C/A/T typesetting experience, one will need to write
a simulator for the device.
Standard PDF fonts have much larger glyph repertoires, are symbol fonts are
explicitly _unstyled_.
_groff_font_(5):
Font description file format
...
A font description file has two sections. The first is a sequence
of directives, and is parsed similarly to the DESC file described
above.
...
The directives above must appear in the first section; those below
are optional.
...
special
The font is special: when the document attempts to format a
glyph that is not present in the formatter’s currently
selected font, the glyph is sought in any mounted fonts that
bear this property. Often, such fonts are unstyled, having
no heavy (bold) or slanted (italic or oblique) variants.
I repeat for emphasis: special fonts are _unstyled_.
Any glyph appearing in running text and would has a visibly inconsistent or
jarring weight when set alongside other glyphs in running text, like letters
or numerals, _should be available in a text typeface_ (font).
Symbol fonts are for unstyled glyphs; dingbats and similar, where the reader
can likely not tell what stroke weight is "correct". And if the document
composer did care, they'd likely want to apply the heavier stroke weight _only
to certain glyphs_ from the symbol font, not the whole thing indiscriminately,
affecting its every glyph as the `bd` request does.
For that application, GNU _troff_ offers the `char` request (and others).
So, yes, I'm looking into this issue, and fixing the assertion failure is a
high priority for me, but, for attempts at faithful reproduction of the old
Unix manuals at issue using PDF (or even PostScript) technology, I suspect
that the control line ".bd S 3 3" is at best superfluous and at worst,
inauthentic.
I think I'd suggest that any "ansvr2.tmac" file simply delete the `bd`
request, because no good will come of its use.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68252>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
