Re: [Groff] widow/orphan control

[Werner LEMBERG]

> > > If you prefer to have paragraphs demarcated by
> > > blank lines, you can set the blank line macro
> > > 
> > > .blm pp
> > > 
> > > but then *all* blank lines would start a new paragraph.
> > 
> > Not necessarily.  Just use the `.ns' request to disable
> > further spacing if there are multiple blank lines.
> 
> Sorry, this is a misunderstanding.  You're right if all the
> paragraph macro did was to space forward a little.  But what
> about things the paragraph macro might do additionally (such as
> perhaps incrementing a counter and inserting a little number in
> the margin for numbered paragraphs (if anybody cared for such
> things))?  This would be triggered by any blank *input* line.

Test the \n[.ns] register whether you still are in no-space mode.
New since 1.17.1.

> However, often you would want a blank line to mean a blank line
> (for example, in source code fragments), and then you'd have to
> explicitly turn the blank-line -> pargagraph translation off at
> the beginning and back on at the end.

This is unavoidable and should be done within a macro to typeset
source code.

> > You are right, I won't change this.  Instead, I'll probably
> > activate the widow protection support in gtroff (see the
> > WIDOW_CONTROL macro in the source files).  The basic idea is
> > to save the last (formatted) output line(s) and defer its
> > output if necessary -- a kind of built-in diversion.
> 
> I'm curious.  Doesn't the notion of "widow" require the concept
> of what a "paragraph" is?  This goes far beyond the traditional
> one-line-at-a-time typesetting of troff (unless augmented by
> macros).  How will troff know what I consider a paragraph?

A hard break, either implicit or explicit, will flush the line cache.
In most situations, this is a reasonable assumption.

> > For example, the effect of `.ns' invoked in a header macro is
> > delayed until saved lines are already output.
> 
> I don't understand.  Isn't that how it's supposed to be?

As soon as a printable item is encountered, no-space mode should be
turned off.  This doesn't happen currently if the line cache is
flushed at the top of a new page.  Assume that a header macro emits
`.ns' and that last two lines of a paragraph (XXX and YYY) are in the
line cache.  In the following example the all input lines have exactly
the width of output lines for simplicity.

For this input

  ...
  XXX
  YYY
  .sp
  AAA
  .sp
  BBB

the correct result at the top of the new page would be

  XXX
  YYY

  AAA

  BBB

but due to the problem we get

  XXX
  YYY
  AAA

  BBB

instead.  XXX doesn't turn off no-space mode.


    Werner