[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/
- [bug #62825] Incorrect section number using \*($n in a header, anonymous, 2022/07/27
- [bug #62825] Incorrect section number using \*($n in a header, G. Branden Robinson, 2022/07/27
- [bug #62825] Incorrect section number using \*($n in a header, G. Branden Robinson, 2022/07/27
- [bug #62825] Incorrect section number using \*($n in a header, anonymous, 2022/07/27
- [bug #62825] Incorrect section number using \*($n in a header, Dave, 2022/07/28
- [bug #62825] Incorrect section number using \*($n in a header, anonymous, 2022/07/28
- [bug #62825] Incorrect section number using \*($n in a header, Dave, 2022/07/28
- [bug #62825] Incorrect section number using \*($n in a header, G. Branden Robinson, 2022/07/28
- [bug #62825] Incorrect section number using \*($n in a header, G. Branden Robinson, 2022/07/28
- [bug #62825] page header info should correspond to last section on the page, G. Branden Robinson, 2022/07/28
- [bug #62825] page header info should correspond to last section on the page,
Dave <=
- [bug #62825] page header info should correspond to last section on the page, anonymous, 2022/07/29