bug-groff
[Top][All Lists]
Advanced

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

[bug #62825] page header info should correspond to last section on the p


From: Dave
Subject: [bug #62825] page header info should correspond to last section on the page
Date: Thu, 28 Jul 2022 22:28:16 -0400 (EDT)

Follow-up Comment #9, bug #62825 (project groff):

[comment #7 comment #7:]
> One of these was the same as in the pile of books I cited
> recently to undermine Ingo's claim that the overwhelming
> majority of publishers in all fields set headers as mandoc(1)
> does.

(Off topic for this bug, but I read his claim more that mandoc was coded to
set headers following (his idea of) publishing tradition.  Maybe I'm just
feeling extra sympathetic towards him, having myself made a brazenly incorrect
claim about headers earlier in this bug report.)

> >  There is the very real problem of breaking backward
> > compatibility even if it does arguably improve output.
> 
> It sounds to me like this was just a straight-up bug.

I agree, but that doesn't address all compatibility concerns.  For instance,
one of Eric Allman's cited use cases (recently removed from the -me manual
(commit 3e281469
<http://git.savannah.gnu.org/cgit/groff.git/commit/?id=3e281469>)) for
redefining $h was providing multi-line headers, which -me does not inherently
support.  But you have to know how much space to leave for the header before
outputting any page content.

It is certainly possible to give the user a way to control this for new -me
documents.  But any historical ones with a redefined $h that changed the
header's height will render very badly after this bug fix, because -me will
simply have no way to know how much vertical space that $h will take up.

This isn't an argument against making the fix, just a caution that back
compatibility needs some careful attention.  And I'm familiar enough with -me
to recognize some of its potential pitfalls; in other packages I'd have no
idea what issues may await.

> My guess is that people simply haven't been putting section
> information in their headers because of this behavior, they
> worked around it, or they got lucky.

Or they failed to check existing practice altogether and assumed, as I
initially did, that the header should reflect the content at the beginning
rather than the end of the page.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62825>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

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