[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)
- Re: [Groff] Re: Adding styles to DESC, (continued)
- Re: [Groff] Re: Adding styles to DESC, Werner LEMBERG, 2004/06/11
- Re: [Groff] Re: Adding styles to DESC, Peter Schaffter, 2004/06/11
- Re: [Groff] Re: Adding styles to DESC, Werner LEMBERG, 2004/06/12
- Re: [Groff] Re: Adding styles to DESC, Peter Schaffter, 2004/06/12
- Re: [Groff] Re: Adding styles to DESC, Werner LEMBERG, 2004/06/14
- Re: [Groff] Re: Adding styles to DESC, Peter Schaffter, 2004/06/14
- [Groff] New \n[.sty] register, Werner LEMBERG, 2004/06/29
- Re: [Groff] Re: Adding styles to DESC, Werner LEMBERG, 2004/06/30
- Re: [Groff] Re: Adding styles to DESC, Peter Schaffter, 2004/06/30
Re: [Groff] Re: Adding styles to DESC, MARSHALL Keith, 2004/06/10
- Re: [Groff] Re: Adding styles to DESC,
Peter Schaffter <=
- Re: [Groff] Re: Adding styles to DESC, Werner LEMBERG, 2004/06/11
- Re: [Groff] Re: Adding styles to DESC, Robert Goulding, 2004/06/11
- Re: [Groff] Re: Adding styles to DESC, Peter Schaffter, 2004/06/11
- [Groff] gtbl, T{ ... T} doesn't work?, Dorai Sitaram, 2004/06/12
- Re: [Groff] gtbl, T{ ... T} doesn't work?, Heinz-Jürgen Oertel, 2004/06/12
- Re: [Groff] gtbl, T{ ... T} doesn't work?, Werner LEMBERG, 2004/06/12
- Re: [Groff] gtbl, T{ ... T} doesn't work?, Robert Goulding, 2004/06/12
- Re: [Groff] gtbl, T{ ... T} doesn't work?, Dorai Sitaram, 2004/06/12
- Re: [Groff] gtbl, T{ ... T} doesn't work?, Ted Harding, 2004/06/12
- Re: [Groff] gtbl, T{ ... T} doesn't work?, Jorgen Grahn, 2004/06/12