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/
