> Well, the AT&T mm macros define .TP with the standard top-of-page
> processing (the mgm macros do not), which is more in keeping with my
> original proposal to define .EOP with the standard end-of-page
> processing. Does that change anyone's mind about the correct
> approach? It makes sense to
Werner LEMBERG writes:
>
> >> As I read your description, the current syntax is:
> >>Define .EOP to change end-of-page processing.
> >>Undefine .EOP to restore the default end-of-page processing.
> >
> > Good point.
>
> I second this.
>
> > It wouldn't be a big deal to define (and docum
>> As I read your description, the current syntax is:
>> Define .EOP to change end-of-page processing.
>> Undefine .EOP to restore the default end-of-page processing.
>
> Good point.
I second this.
> It wouldn't be a big deal to define (and document) another macro for
> the standard e
Mike Bianchi writes:
>
> As I read your description, the current syntax is:
> Define .EOP to change end-of-page processing.
> Undefine .EOP to restore the default end-of-page processing.
Good point. I hadn't considered that use case; I assumed that people
who define .EOP leave it def
On Wed, Jun 02, 2010 at 11:36:32AM -0400, Larry Jones wrote:
> The user-defined .EOP macro in mgm overrides the normal end of page
> processing, but there's no convenient way to invoke said normal
> processing if one merely wants to augment it rather than completely
> replacing it. It seems to me
The user-defined .EOP macro in mgm overrides the normal end of page
processing, but there's no convenient way to invoke said normal
processing if one merely wants to augment it rather than completely
replacing it. It seems to me that it would be better to pre-define .EOP
to do the normal end of pa
