[Groff] Re: Adding styles to DESC

[Peter Schaffter]

On Wed, Jun 09, 2004, Werner LEMBERG wrote:
> > I create font files in font/devps/ with the names FRU
>                          ^^^^^^^^^^^
> Don't use this directory.  Since 1.18.1, user-defined PS fonts should
> be placed into <prefix>/groff/site-font/devps/ (<prefix> is normally
> /usr/local/share).

Here's the output of ls /usr/local/share/groff from my latest build
of 1.19.2 from the repository:

    1.19.2
    site-tmac

As you can see, no /site-font.  Did I miss something when doing
./configure?  At any rate, /site-font is something I've always
wanted, so I'll create the dir myself.  Still, it would be
interesting to know why it wasn't created by default during
make/make install.

> > Now, in the DESC file, I add to the default line, "styles R I B BI",
> > the extra styles "L LI BL BLI UB".
> 
> Uh, oh, this is completely wrong.  Don't touch the contents of the
> DESC file except you want to change the default fonts of groff for all
> documents.  Instead, use the `.sty' request.  From groff.info, node
> `Font Families':
> 
>      The `styles' command in the `DESC' file controls which font
>      positions (if any) are initially associated with styles rather
>      than fonts.  For example, the default setting for POSTSCRIPT
>      fonts
> 
>           styles R I B BI
> 
>      is equivalent to
> 
>           .sty 1 R
>           .sty 2 I
>           .sty 3 B
>           .sty 4 BI

It was this very same snippet from the info file that lead me
astray.  I misread "...is equivalent to" as meaning "is equal to"
(IOW as an operator).  If "styles <whatever>" = ".style n <whatever>",
then ".style n <whatever> = styles <whatever)" (provided that the
"fonts" line in DESC matched up in terms of number of fonts).

> So, you should say
> 
>   .sty \n[.fp] L
>   .sty \n[.fp] LI
>   .sty \n[.fp] BL
>   .sty \n[.fp] BLI
>   .sty \n[.fp] UB
>   .
>   .fam FRU
>   .ft LI

This, as you may have guessed, is exactly what I wanted to
avoid. :)

> You should read the groff.info stuff from section `Font Families'.
> Reason for the problem you describe is that after `.fam T' the style
> `LI' (set by .ft) is still active.  groff consequently tries to access
> font `TLI' which fails, thus the .fam command is ignored.

Yes, I rather suspected this was the case.  I read and re-read the
info node to which you refer, but I fear, in this case, my brain
was trying to make it mean what I wanted it to mean, instead of
seeing what it really meant.

(If I may be permitted an observation, the info docs are superb.  I
use TkInfo to browse them, and don't know how I'd get along without
them.)

My explorations into styles has to do with the "square peg into a
round hole" design concept of the mom macros.  Inasmuch as possible,
I want mom users to do "what comes naturally," without having to
read the groff man and info docs extensively.

Hence, if a user has added a "family" to her/his personal collection
of devps fonts, and that family contains, say, a suite of font
weights (e.g. light, medium, bold, heavy, black) and, within
those weights, the styles roman, italic, condensed, extended and
outline, "what comes naturally" would be to set the family (.FAM,
in mom-speak), then access the desired font(s) as required (.FT, in
mom-speak).

Thus, using my Frutiger example, a user could add:

    FRUL
    FRULI
    FRUR
    FRUI
    FRUB
    FRUBI
    FRUBL
    FRUBLI
    FRUUB

to their font collection.  Then, in mom

    .FAM FRU

would set the family to Frutiger, and any of the following would
access the desired weight+style

    .FT L
    .FT LI
    .FT R | I | B | BI
    .FT BL
    .FT BLI
    .FT UB

What I'm wondering, then, is: would there be a problem with adding
these (and other) styles to om.tmac (with .sty), then re-writing the
.FAMILY macro so that whenever it's called, it precedes the .fam
call with .ft R?  If there isn't a problem, I can then expand the
.FAMILY section of the momdocs, instructing mom users how to add
entire font families using naming conventions like the above.

Thoughts, anyone?

-- 
Peter Schaffter

Author of _The Schumann Proof_, appearing fall, 2004
(pub. RendezVous Press, Canada)