Re: Footnote line length ratio to current line length

[T. Kurt Bond]

> > (I think making setting FR effective before the next footnote, like
> > setting FL in one column mode, would take rewriting par@reset to
> > recalculate fn:MCLL every time, instead of just after a .MC.)

> I'm not entirely sure what to do about this.  How much fidelity to AT&T
> ms behavior do people expect from ms?  I've begun to surmise that the
> answer is "a lot less than they expect from man(7) documents".

That's a thorny question.  I actually do expect that unless I use the
extensions of groff or Heirloom troff explicitly I'll get a document that
is processed successfully and that produced output that is as nearly as
possible to what the classical implementations of troff would have
produced.  This means that documents that I wrote 30 years ago and
documents others wrote even longer ago can still be processed and produce
the correct output.  (Sometimes I have to make changes to other programs I
use to build my documents, but not to the troff source of my document.)
Troff has done better in terms of backwards compatibility than has LaTeX,
in my experience.

Adding FR as an extension seems fine: documents that don't set it will
still get the 5/6 ratio, while other documents have the option for
producing what is to some eyes a better appearance by explicitly opting in.


On Sun, Nov 15, 2020 at 6:57 AM G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> At 2020-11-13T13:59:27-0500, T. Kurt Bond wrote:
> > Is there any chance of the footnote ratio change I discuss getting in
> > the upcoming groff release?  Should I add it as a bug at
> > savannah.gnu.org?
>
> Probably a good idea.  As you may be aware, I am updating and expanding
> Larry Kollar's ms.ms document with an eye to its inclusion in groff
> 1.23.0.
>
> Due to the way I work, this has involved me learning a lot about ms and
> its history.
>
> > On Thu, Aug 6, 2020 at 11:53 AM T. Kurt Bond <tkurtbond@gmail.com>
> wrote:
> >
> > > groff_ms(7) says that changing the number register FL is effective
> > > at the next footnote.  That seems to be true only for one column
> > > text.
>
> This behavior is worth trying to reproduce in Heirloom Doctools troff.
>
> > > In multicolumn text you have to change the undocumented fn:MCLL
> > > after calling .MC.  fn:MCLL is an alias for the number register
> > > pg@fn-colw, which is set when .MC is called.  (.2C calls .MC to do
> > > the work, so we only have to worry about .MC.)
> > >
> > > Is fn:MCLL intended to be ms internal use only, or is intended to be
> > > available to users?
>
> Definitely internal.  This is clearly documented in the in-progress
> rewrite (alas, it's not committed yet).  I'm attaching it, and let's see
> if I remember to actually do so before sending.
>
> > > I don't like having the line length of the footnotes only 5/6 the
> > > width of the columns: I like them to be the full width of the
> > > current line, whether that is in one column mode or multicolumn
> > > mode.  I'd like to be able to change that default, to avoid having
> > > to change the footnote line length in multicolumn mode using the
> > > undocumented fn:MCLL.
>
> I think the reason for this 5/6 ratio is because that's what AT&T ms did
> in the 1970s, and possibly every ms implementation ever since.
>
> > > I propose adding a string variable, FR (footnote ratio), that
> > > defaults to to 5/6 for compatibility and replaces the uses of the
> > > literal 5/6 for setting footnote line length.  You can set this at
> > > the beginning of your document, or before each .MC or .2C.  For my
> > > use I'd always set it to 1, making the footnote line length the same
> > > as the line length.
> > >
> > > (I think making setting FR effective before the next footnote, like
> > > setting FL in one column mode, would take rewriting par@reset to
> > > recalculate fn:MCLL every time, instead of just after a .MC.)
>
> I'm not entirely sure what to do about this.  How much fidelity to AT&T
> ms behavior do people expect from ms?  I've begun to surmise that the
> answer is "a lot less than they expect from man(7) documents".
>
> Regards,
> Branden
>


-- 
T. Kurt Bond, tkurtbond@gmail.com, https://tkurtbond.github.io