[Top][All Lists]

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

Re: [Groff] Re: Adding styles to DESC

From: MARSHALL Keith
Subject: Re: [Groff] Re: Adding styles to DESC
Date: Thu, 10 Jun 2004 09:58:25 +0100

>> > 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.

Even if styles are added locally, (within any document scope), using
the .sty request, will this same problem not still potentially occur?
Surely, even in this case, if the currently selected style, even when
added with a .sty request, is not available in some other font family,
then any attempt to switch to that family with the .fam request will
fail, unless the active style is first changed to one that the new
font family *does* include?

> 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 will.
A consequence of this, of course, would be that every font family
change would also imply a change to the `R' style.  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.

Best regards,

reply via email to

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