Hi Branden, G. Branden Robinson wrote on Wed, Jun 30, 2021 at 08:32:35PM +1000: > At 2021-06-28T15:53:48+0200, Ingo Schwarze wrote:
[...] >> I realize that non-continuous rendering mode is very important for >> PostScript and PDF output, but i don't really care what it does on >> the terminal. I think all that really matters on the terminal is >> continuous rendering mode. > I think that's true for most users. The useful thing about > non-continuous rendering mode to the terminal for me is that no > within-macro-package logic actually cares whether the formatter is > PostScript or PDF, instead, conditionals tend to be predicated on the cR > register instead. It's much easier for me to catch regressions in > output by diffing text files, so that's what I do. That's a fair argument, and another reason for not breaking non-continuous rendering mode for terminal output (apart from the generic reason that if any feature is provided, it should not be broken). >> In some areas, tradition is of some importance, but i'm not convinced >> the differences between continuous and non-continuous rendering mode >> are such an area. I may be missing something, though. > Two or three years ago I played around with adding a PL register to > groff's an-old.tmac to permit the user to tune the page length. My idea > was that it might be interesting to set it to exactly the height of the > terminal window (or maybe minus one to accommodate less(1)'s prompt), so > that the headers and footers would remain fixed in position, simulating > a page-turning experience. I'm not yet sure whether that will indeed be useful in some situations, but it seems possible that it might be. I think it will hardly be a high-priority feature, but if it can be done without relevant downsides, i don't expect that i would be opposed to it. Even though it seems likely that the feature will be fragile, because how well it will work probably depends on implementation details of the pager(s)... [...] > I can image a user who might prefer such an experience at the terminal, > however, because it's not _purely_ a matter of fun--one of my gripes > about our HTML output, apart from the rather dire cosmetics that can > occur, is that headers and footers are completely suppressed, which > means most of the information provided to the .TH call is simply not > available. I'm thinking here of the "extra1" and "extra2" arguments, > which go in the footer and which many projects (including groff) use to > record a project name and modification date. > > I noticed that groff's mdoc implementation puts that sort of > information at the page footer even when HTML is output. I think our > man(7) output should do the same. > > I have no immediate plans to do anything about this, but I am curious > what others think. I think for the purposes of manual pages, working on groff HTML output is mostly a waste of time because i see no realistic chance of achieving decent quality, not even if somebody invested huge effort. That said, i think you are right that for any output mode, silently dropping text that the document author provided for display is always a bad idea. Yours, Ingo
