On Tue, Aug 27, 2013, Robin Haberkorn wrote:
> found and fixed another bug in the mom macros.
> Her handling of NUMBER_LINES if tbl is used was buggy.
> If you used NUMBER_LINES to turn on line numbering, turned it off and
> then used tbl tables, the table was numbered. Naturally if you resumed
> l
On Tue, Aug 27, 2013, Tadziu Hoffmann wrote:
> Otherwise, how would you do it? Well, the section macro could
> perhaps query register "nl" (vertical position of last printed
> text base-line), but that may be a bit chancy (depending on,
> for example, whether you output or not a page header on tha
On Mon, Aug 26, 2013, Tadziu Hoffmann wrote:
>
> > > The problem you see is related to header traps. [...] and
> > > this behaviour is not controllable by `rs'. It seems that
> > > after the top header trap mom plants other, probably unused
> > > vertical traps.
>
> > Any suggestion for a clea
On Sun, Sep 01, 2013, Johann Höchtl wrote:
> And mom-specific:
> * Does MOM have a macro for page break (or is .bp save?)
Use NEWPAGE. There are a few conditions that mitigate against using
.bp safely all the time.
> and a way to set text in two columns with automatic overflow, when
> the main t
On 2013-09-03 21:45, Peter Schaffter wrote:
On Sun, Sep 01, 2013, Johann Höchtl wrote:
And mom-specific:
* Does MOM have a macro for page break (or is .bp save?)
Use NEWPAGE. There are a few conditions that mitigate against using
.bp safely all the time.
The Documentation for mom is superb,
On Tue, Sep 03, 2013 at 01:40:31PM -0400, Peter Schaffter wrote:
> On Tue, Aug 27, 2013, Ulrich Lauther wrote:
> > However, when the user explicitely requests a new page, this seems
> > not to be needed: he/she knows that following text goes to a new page
> > and should be free to position it where
On Tue, Sep 03, 2013, Johann Höchtl wrote:
> On 2013-09-03 21:45, Peter Schaffter wrote:
> >>and a way to set text in two columns with automatic overflow, when
> >>the main text is set single-column?
> >
> >I'm having trouble visualizing this, but I think the answer is no.
> Yes, I was to succinct.
On Tue, Sep 03, 2013, Ulrich Lauther wrote:
> why have I to use ADD_SPACE instead of SP just because I am at the
> top of the page?
> Seems to me an unneeded complication. Is there a deeper reason to
> make SP disfunctional after an *explicit* page break?
The only way to disable no-space mode aft