bugGNU roff - Bugs: bug #61453, want native mechanism for...

 
 

bug #61453: want native mechanism for continuous (non-paginated) rendering

Submitter:  Dave <barx>
Submitted:  Wed 10 Nov 2021 12:00:40 AM UTC
   
 
Category:  Core Severity:  1 - Wish
Item Group:  Feature change Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 15 Feb 2024 10:14:10 PM UTC, comment #9: 

In bug #65190 (which is a special case of this bug, applying to just the -man and -mdoc macro packages), I posted this comment, which is more relevant here, as it shows some historical demand for this feature in macro packages other than those two.

There may well be more, but it's not an easy thing to search because there's no historically consistent terminology for the concept.

Dave <barx>
Group Member
Tue 23 Jan 2024 08:28:37 PM UTC, comment #8: 

comment #7:

> We could then migrate (some of) our macro packages to support
> continuous rendering under this approach rather than the
> current one, which has caused other problems.  See bug #57665
> and bug #63960.


and now bug #65189.

Dave <barx>
Group Member
Thu 30 Mar 2023 12:42:29 PM UTC, comment #7: 

At present I'm thinking that resolving bug #63587 will enable this well enough.

I'm a little nervous of meddling with the semantics of a negative page length given the potential for interaction with negative vertical drawing positions.

For one thing, one might reasonably draw a geometric primitive, like an arc, from a negative vertical (or horizontal, for that matter) drawing position.

As #63587 proposes, we could fix the built-in, read-only register to "INT_MAX" instead of ten thousand.

We could then migrate (some of) our macro packages to support continuous rendering under this approach rather than the current one, which has caused other problems.  See bug #57665 and bug #63960.

Certainly, doing


.pl \n[.R]u


lays a trap for the document/macro package author if they unthinkingly do something like


.pl +1v


somewhere, as groff man(7) and mdoc(7) do.  This will cause an arithmetic overflow error.

However, incrementing the page length appears to be an uncommon operation.


$ git grep 'pl +'
contrib/hdtbl/hdmisc.tmac:.    pl +1            \"      without arg increase page length by 1v
contrib/hdtbl/hdmisc.tmac:.    pl +\\$1         \"      otherwise use \\$1
doc/groff.texi:.pl +1v
tmac/an.tmac:.    pl +(\\n[an-amount]u - \\n[.t]u + 1v)
tmac/an.tmac:.    if ((\\n[.p] - \\n[nl]) <= \\n[.V]) .pl +1v
tmac/an.tmac:.    pl +1v
tmac/an.tmac:.      pl +1v
tmac/an.tmac:.  ie \\n[cR] .pl +1v
tmac/an.tmac:.    pl +1v
tmac/an.tmac:.  if \\n[cR] .pl +1v
tmac/mdoc/doc-common:.    pl +(\n[doc-amount]u - \n[.t]u + 1v)
tmac/mdoc/doc-common:.  ie \n[cR] .pl +1v
tmac/mdoc/doc-common:.    pl +1v
tmac/mdoc/doc-common:.    if ((\n[.p] - \n[nl]) <= \n[.V]) .pl +1v
tmac/mdoc/doc-common:.    pl +1v
tmac/mdoc/doc-common:.      pl +1v


I expect the man(7) and mdoc(7) instances to go away when this ticket is resolved, and hdtbl.tmac needs to be audited on this point.  (I think it targets only HTML output, where the meaning of "page length" is not obvious.)

In principle, this approach could be adapted to conventional macro packages; pending footnotes could be flushed at appropriate times (the end of a section, chapter, or document).

The above also suggests that we have an example to review in our Texinfo manual, if/when this ticket is addressed.

G. Branden Robinson <gbranden>
Group administrator
Tue 11 Jan 2022 03:12:37 AM UTC, comment #6: 

If we get this implemented, I don't see that there's much in the way of applying it to typesetter devices as well, and then lo and behold we have support for machines that render to spools of paper instead of pages--one of the properties of the C/A/T, if you'll recall.

Nothing new under the sun.  :)

G. Branden Robinson <gbranden>
Group administrator
Tue 28 Dec 2021 09:43:40 PM UTC, comment #5: 

comment #4:

> I guess would only add that the zero-sized vertical margins
> aren't anything special that the `an` package does; these are
> the margins inherited from troff's defaults.


Good point; the -man macros to handle this are really just dealing with things like calls to .ne and .bp.

But even .ne wouldn't need any special handling if native roff allowed conceptually setting the page length to infinity: then all .ne calls would turn into no-ops, since there would by definition always be room on the current page.

Dave <barx>
Group Member
Tue 28 Dec 2021 09:48:43 AM UTC, comment #4: 

comment #3:

> original submission:
> > groff could provide a new, dedicated tmac file for this task
> > and properly document its inclusion and use.  The existing
> > macros in an.tmac could be leveraged for this if they're
> > suitable for general use.
>
> My guess now is that they aren't.  As I understand it, in contrast to the one-long-page system the Texinfo manual gives an example of, the -man macros set top and bottom margins of internal pages to 0, so that, even though nroff outputs multiple "pages," the breaks between them are invisible, effectively looking like one long page.
>
> This is fine in the -man language, which doesn't support footnotes.  But it's unclear how this could be generalized to work with the full-service macro packages, most of which do include mechanisms to render footnotes at the bottom of the page.  In the one-long-page case, this pushes footnotes to the end of the output.  But for multiple pages with invisible page breaks, this would effectively put footnotes at random-seeming places in the middle of the text.
>
> This isn't to say that the problem is insurmountable, only that a straightforward adaptation of the -man system probably won't cover the complexities of existing macro packages or unfettered roff.


Hi, Dave!

I would not have described the man(7) package's "continuous
rendering mode" that way, but you are in fact correct.  It can
and often does render multiple pages, but because headers and
footers are disabled, the troff page boundaries are difficult to
discern.

I guess would only add that the zero-sized vertical margins
aren't anything special that the `an` package does; these are
the margins inherited from troff's defaults.

G. Branden Robinson <gbranden>
Group administrator
Thu 23 Dec 2021 08:04:26 AM UTC, comment #3: 

original submission:

> groff could provide a new, dedicated tmac file for this task
> and properly document its inclusion and use.  The existing
> macros in an.tmac could be leveraged for this if they're
> suitable for general use.


My guess now is that they aren't.  As I understand it, in contrast to the one-long-page system the Texinfo manual gives an example of, the -man macros set top and bottom margins of internal pages to 0, so that, even though nroff outputs multiple "pages," the breaks between them are invisible, effectively looking like one long page.

This is fine in the -man language, which doesn't support footnotes.  But it's unclear how this could be generalized to work with the full-service macro packages, most of which do include mechanisms to render footnotes at the bottom of the page.  In the one-long-page case, this pushes footnotes to the end of the output.  But for multiple pages with invisible page breaks, this would effectively put footnotes at random-seeming places in the middle of the text.

This isn't to say that the problem is insurmountable, only that a straightforward adaptation of the -man system probably won't cover the complexities of existing macro packages or unfettered roff.

Dave <barx>
Group Member
Sun 12 Dec 2021 12:32:19 AM UTC, comment #2: 

original submission:

> But this system has several drawbacks:


One additional one:

  • It currently doesn't work when using the .2c macro of the -me macro set, due to bug #55081.
Dave <barx>
Group Member
Wed 24 Nov 2021 11:46:25 PM UTC, comment #1: 

An interim solution might be to beef up the documentation about the -man method.  Providing a fully functional example for the .em method and only a terse summary, in a footnote, of the -man one, implies the former is the preferred one.

Arguably, the latter technique is merely a clever combination of the building blocks already documented in the Texinfo manual, and the manual certainly can't and shouldn't be expected to document every novel combination of primitives.  But the same argument could apply to the .em example as well; usage of .em itself is already illustrated in a prior example, so the second example exists only to show a way to do continuous rendering, while introducing no new groff concepts.

Dave <barx>
Group Member
Wed 10 Nov 2021 12:00:40 AM UTC, original submission:  

It is common when sending groff output to the terminal to want no "page breaks" in the document.  But there is currently no simple way to achieve this.

One way of doing it is documented in the Texinfo manual under discussion of the .em request.  But this system has several drawbacks:

  • As explained just below the example in the manual, it can interfere with any other use of groff's sole end-of-input trap.
  • As mentioned in comment 1 of bug #55124, it prevents footnotes (or other diverted text placed relative to the page bottom) from being output.
  • It requires first establishing a dummy "page length" that will definitely be greater than the number of lines output, which the document author may not know (and which may change drastically if the width of the document is set to be that of the terminal).


A more sophisticated system is that used in the -man macros: see the macro .an-ne and the next few under it in tmac/an.tmac.  This method seems fairly robust but requires several macros to achieve, which is not the ideal situation for behavior that is commonly desired.  It is also, incidentally, mostly undocumented: a footnote in the aforementioned .em documentation (and that added only a year ago) gives a seven-word overview of the concept but requires each user to re-invent the wheel or track down the appropriate macros in an.tmac.

Thus this feature request for a simple mechanism to suppress page breaks on any of the grotty devices.  This could take the form of a new request, but perhaps a simpler solution is that proposed in bug #55124: changing the mostly useless current behavior of a negative .pl value to enable continuous rendering.

As an alternate to altering the groff code, groff could provide a new, dedicated tmac file for this task and properly document its inclusion and use.  The existing macros in an.tmac could be leveraged for this if they're suitable for general use.

Dave <barx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-01-11 gbranden Summary[nroff] request native mechanism for continuous (non-paginated) rendering want native mechanism for continuous (non-paginated) rendering
    2022-01-11 gbranden CategoryDriver - others/general Core

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code