[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Re: Adding styles to DESC

From: Peter Schaffter
Subject: Re: [Groff] Re: Adding styles to DESC
Date: Thu, 10 Jun 2004 11:07:17 -0400
User-agent: Mutt/1.5.4i

On Thu, Jun 10, 2004, MARSHALL Keith wrote:
> >> > 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.  ...
> Surely the issue here is not so much that you shouldn't modify the DESC
> file to add styles, but rather that if you do, you must recognise that
> you are making those new styles global to the associated device scope?
> It seems to me that this is exactly what Peter is trying to achieve.
> What he appears to have missed, however, is that to properly globalise
> his additional styles, he needs to extend *all* of the existing font
> families, to include variants in each of the new styles -- failing to
> do so leaves the potential for the problem he has experienced, namely
> that attempting to change the font family, with the .fam request, will
> fail if the current style is not available in the new family.

Yes, indeed, this is what I discovered.  Needless to say, it was
upon discovering that that I realised I had to come up with another
mechanism for adding additional weights and styles.

> Even if styles are added locally, (within any document scope), using
> the .sty request, will this same problem not still potentially occur?

Yes, it does.

> > 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.
> I can't see any problem with this, except that it requires an `R'
> style to exist for the font family you intend to change to with the
> .FAMILY macro, but it is not an unlikely presumption that [it] will.

My thinking exactly.  And it seems to me that just about any family
that doesn't contain an R style is most likely not a family at all,
but a decorative font, something like, say Arnold-Boecklin.  In
which case, it can be made a downloadable font with an associated
.pfa file, and thus requires no style at all.

> A consequence of this, of course, would be that every font family
> change would also imply a change to the `R' style.

I've been trying to imagine whether an automatic change to the R
style whenever .FAMILY is called would present an unreasonable
annoyance to mom users.  Unfortunately, I have only my own
experience over the past couple of decades to rely on, but that
experience shows me that rarely, if ever, do I want a complete
family change unless I expect the change to default to Medium
Roman.  Whenever I do need an occasional font not contained within my
current family, I use .FT (the mom version of .ft) with the full
family+style argument.  It's one of the nice things about groff
that I can actually do that.

> Alternatively, you could adopt the technique which is given in the
> groff `Font Families' info node, utilising an intermediate switch
> to a dummy font mounted in position zero, but I think that amounts
> to much the same thing.

Or, since .FT in mom stores the argument passed to it as a string,
do an intermediate change to R, switch families, then restore the
font string previously in effect.  But personally, I don't think this
is the behaviour mom users would want.  I mean, how often does one,
working in, say, Helvetica Medium Italic, want to switch completely
to Garamond and preserve the font weight/style at Medium Italic?

In tests yesterday, I added the following styles to om.tmac:

    L      =  Light Roman
    LI     =  Light Italic
    LCD    =  Light Condensed Roman
    LCDI   =  Light Condensed Italic
    LEX    =  Light Extended Roman
    LEXI   =  Light Extended Italic
    CD     =  Medium Condensed Roman
    CDI    =  Medium Condensed Italic
    EX     =  Medium Extended Roman
    EXI    =  Medium Extended Italic
    BCD    =  Bold Condensed
    BCDI   =  Bold Condensed Italic
    BEX    =  Bold Extended
    BEXI   =  Bold Extended Italic
    BL     =  Black Roman
    BLI    =  Black Italic
    UBL    =  Ultra-Black Roman

and created several partial and complete groff families using them:
Garamond (GD), Gill Sans (GS), Futura (FUT) and Frutiger (FRU).
Accessing them with .FAM (with the auto-switch to R), then using .FT
to get the desired fonts, worked like a charm.  Other than the
obvious fact that one has to take care that the style extension
doesn't conflict with a family name (e.g. Condensed can't be C, or
it conflicts with Courier Roman), can anyone foresee any problems
with this scheme?

Peter Schaffter

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]