Follow-up Comment #33, bug #64155 (group groff):
[comment #32 comment #32:]
> [comment #28 comment #28:]
> > [comment #27 comment #27:]
> > Specifically, am I correct to claim either of the following?
> >
> > A. "[G]iven that mom has her own system of managing fonts, and part of
her contract with the user [...] is that [the] user will not go behind her
back and start invoking *roff requests." is a false statement. (Possibly an
exaggeration.)
>
> Oversimplification, possibly my fault. You got the idea from this bit of
the documentation:
>
> "In some cases, mom’s typesetting macros merely imitate groff primitives.
In others, they approach typesetting concerns in conceptually new ways (for
groff, at least). This should present no problem for newcomers to groff who
are learning mom. Old groff hands should be careful. Just because it looks
like a duck and walks like a duck does not, in this instance, mean that it is
a duck. When using mom, stay away from groff primitives if mom provides a
macro that accomplishes the same thing."
Yes. I haven't read anything like all of _mom_'s documentation, but the
foregoing sounds a fairly large bell in my head. I likely did overinterpret
it.
> That's not a contract, it's a recommendation. I don't want users imagining.
for example, that they can use either .ps or .PT_SIZE interchangeably (or
.ft/.FT) and expect the same results. E.g. if AUTOLEAD is enabled, .PT_SIZE
changes the pointsize and updates the leading. Plain .ps only changes the
size, hence the recommendation to stay away from groff primitives *if mom
provides a macro that accomplishes the same thing.* There a number of macros
where the documentation explicitly states that using a primitive instead of a
macro is fine.
Acknowledged.
> I'm not comfortable with the statement "mom has her own system of managing
fonts." Other than that .FAM and .FT perform checks and set registers needed
by other macros, and the inclusion of pre-defined supplementary styles (none
loaded in positions 1-4), there is nothing unique about mom's font
management.
No indeed; given your clarification above, item A is greatly overstated.
> > B. The statement "By issuing appropriate formatter instructions, you can
override these defaults before your document writes its first glyph." in our
manual should be dropped, or revised to stipulate that some macro packages
(namely _mom_), will assume that that before a document requests a glyph to be
formatted, mounting position 1 will be assigned to a style named 'R'.
>
> I'm confused. The docs currently say, "The default mounting position, and
therefore style, is always '1' ('R')" Why would this suddenly only apply to
"some" macro packages? I don't think the B. statement should be dropped, but
I would change "these defaults" because the only formatter flag pertinent to
that section of the documentation is -f <family>.
I think I can probably leave this item as-is. I certainly should not add any
special caveat about _mom_, but I think the "these defaults" sentence can stay
once the larger context, an introduction to _groff_'s font concept, is
considered.
Here is that context.
5.19 Using Fonts
================
In digital typography, a "font" is a collection of characters in a
specific typeface that a device can render as glyphs at a desired
size.(1) (*note Using Fonts-Footnote-1::) A 'roff' formatter can change
typefaces at any point in the text. The basic faces are a set of
"styles" combining upright and slanted shapes with normal and heavy
stroke weights: 'R', 'I', 'B', and 'BI'--these stand for roman, italic,
bold, and bold-italic. For linguistic text, GNU 'troff' groups
typefaces into "families" containing each of these styles.(2) (*note
Using Fonts-Footnote-2::) A "text font" is thus often a family combined
with a style, but it need not be: consider the 'ps' and 'pdf' devices'
'ZCMI' (Zapf Chancery Medium italic)--often, no other style of Zapf
Chancery Medium is provided. On typesetters, at least one "special
font" is available, comprising "unstyled" glyphs for mathematical
operators and other purposes.
Like the AT&T 'troff' formatter, GNU 'troff' does not itself load or
manipulate a digital font file;(3) (*note Using Fonts-Footnote-3::)
instead it works with a "font description file" that characterizes it,
including its glyph repertoire and the "metrics" (dimensions) of each
glyph.(4) (*note Using Fonts-Footnote-4::) This information permits the
formatter to accurately place glyphs with respect to each other. Before
using a font description, the formatter associates it with a "mounting
position", a place in an ordered list of available typefaces. So that a
document need not be strongly coupled to a specific font family, in GNU
'troff' an output device can associate a style in the abstract sense
with a mounting position. Thus the default family can be combined with
a style dynamically, producing a "resolved font name". A user-specified
font name that combines family and style (or refers to a font that is
not a member of a family) is already "resolved".
Fonts often have trademarked names, and even Free Software fonts can
require renaming upon modification. 'groff' maintains a convention that
a device's serif font family is given the name 'T' ("Times"), its
sans-serif family 'H' ("Helvetica"), and its monospaced family 'C'
("Courier"). Historical inertia has driven 'groff''s font identifiers
to short uppercase abbreviations of font names, as with 'TR', 'TI',
'TB', 'TBI', and a special font 'S'.
The default family used with abstract styles is initially 'T'.
Typically, abstract styles are arranged in the first four mounting
positions in the order shown above. The default mounting position, and
therefore style, is always '1' ('R'). By issuing appropriate formatter
instructions, you can override these defaults before your document
writes its first glyph.
Terminals cannot change font families and lack special fonts. They
support style changes by overstriking, or by altering ISO 6429/ECMA-48
"graphic renditions" (character cell attributes).
I've set the status back to "Confirmed" because my way forward--for the time
being--seems clear.
I think Dave's point in comment #31 is worthwhile and demands further
consideration. I don't relish the labor or I/O expense of making a `fam`
request hit the file system repeatedly, speculatively loading every registered
style for the family being switched to, but maybe that is what is warranted.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64155>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
