[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: Fri, 11 Jun 2004 22:48:42 -0400
User-agent: Mutt/1.5.4i

On Fri, Jun 11, 2004, Werner LEMBERG wrote:
> > It was this very same snippet from the info file that lead me
> > astray.  I misread " 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).
> If you can provide a better formulation which avoids this misleading
> possibility, please do so -- English isn't my mother tongue...

No, your English is well-nigh perfect.  The misreading was mine and
mine alone.
> > 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?
> Preceding with .ft R might fail in case the user has selected a font
> family which doesn't have an `R' style.

Which I thought of, but only after making the suggestion.
Obviously, setting a dummy font with .fp 0 and calling .ft 0 before
.fam makes more sense than simply calling .ft R.

> This is not as unlikely as it appears --in LaTeX, *all* fonts
> get both a `shape' and a `family' tag (and a `series' tag).

This is exactly what I'm hoping can be accomplished somehow with
groff, but without major changes to the way groff functions
presently.  And without changing the way font/devps is currently set
up.  I worry that there are groff users who may have already rolled
their own solutions to the family/weight/shape problem by working
within the constraints groff currently imposes, and that any change
to groff may break their setup.

> As trivial as the font selection mechanism in groff seems to be, it
> can be tricky to catch errors, providing meaningful defaults and
> warning messages.

Indeed.  The major issue, as I see it is: what constitutes a
"meaningful default"?  If a user calls .fam <m> when style <n> is
active, but fam <m> has no style <n>, how should groff behave?  By
selecting a (hypothetical) first "style" that does exist for 
family <m>, or by reverting to a something like the dummy font?
> What do you think about adding two conditional tests like this:
>   .if F <font>   \" true if <font> can be found by troff --
>                  \" the font isn't loaded
>                  \" if <font> is a style, and the style is registered,
>                  \" and <family> is the current family,
>                  \" test whether concatenation of <family> and <font>
>                  \" exists

I like this a lot.  But I'm thinking that what's also needed is a
string-valued register containing the name of the current style,
say, \[.sty], which would behave like \n[.fn] but without the
family name being tacked onto the beginning.  That would give macro
writers the flexibility to determine for themselves how they want
groff to respond to .fam requests.  In the case of the mom macros,
I'd probably do something like this inside the .FAMILY macro:

    .fam \$1
    .ie F \n[.fam]\n[.sty] \{\
    .   ft \n[.sty]
    .el \{\
    .   ab Family \n[.fam] contains no font \n[.sty]

>   .if S <style>  \" true if <style> has been registered, either via
>                  \" the DESC file or with .sty

Not sure I understand the need for this, but then I'm a bit
brain-fried today. :)

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]