groff
[Top][All Lists]
Advanced

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

Re: [Groff] Proposed revised START macro for mom


From: Peter Schaffter
Subject: Re: [Groff] Proposed revised START macro for mom
Date: Sat, 11 Jan 2003 02:09:05 -0500
User-agent: Mutt/1.0.1i

James --

On Wed, Jan 08, 2003, James J. Ramsey wrote:
> > #DOCHEADER_LINES is actually quite important, for
> > the fine-tuning reason
> > you give above.  
> >
> > Therefore, the incrementing register
> > #DOCHEADER_LINES needs to go back
> > into your macros.

I see in your "revised proposed revised" macros post that you've decided
to go the diversion route to establish the depth of the docheader.  I
haven't had time to test your proposal, but in principle, it's a more
elegant solution to the post-docheader spacing adjustment problem than
my approach.  Presuming there aren't any bugs, or if there are, they're
easily fixed, we'll go with your suggestion.

I believe I originally went with "count the lines and multiply by the
leading to get the depth" because I was seeing most docheaders as having
a uniform leading (user-definable as a +|- value of the overall document
lead with .DOCHEADER_LEAD).  Users wanting to create non-standard
docheaders are encouraged, in the docs, to design and typeset their own
in conjunction with

    .DOCHEADER OFF <distance from page top to first desired baseline of running 
text>

However, in the instance where a user wants a standard docheader AND
wants to futz around with line-by-line leading (via \*[ALDn] and friends
in the various strings that go into the docheader), your solution gives
greater flexibility.

> One thing, though. Internal strings like $TITLE_FAM,
> $TITLE_FT and $TITLE_PT_SIZE, etc. can be replaced
> with absolute values like P, R, or 24, so, as you
> said, users who redefine the *_DOCHEADER macros can
> easily avoid using those internal strings simply by
> just using the absolute values instead.

Or, more in keeping with the mom's general philosophy, users can
(should?) change the style of docheader elements with the control
macros

.TITLE_FAMILY
.TITLE_FONT
.TITLE_SIZE

etc.

Frankly, when it's a question of setting up a reusable style sheet for
docheaders, I prefer to create a separate file containing docheader
element control macros and sourcing that file at the top of my docs.  I
confess I didn't really give much thought to users going into om.tmac
itself to do the same thing.

-- 
        +-----------------------------------------------------------+
        | "For-profit medical care is the Hippocratic equivalent of |
        |                   for-profit religion."                   |
        +-----------------------------------------------------------+
PTPi
Peter Schaffter
31, Curé-André-Préseault
Appt. 22
Gatineau (Québec)
CANADA  J8T 6E4

A confirmed GNU/Linuxer. Sorry, I don't do Windows.

reply via email to

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