bugGNU roff - Bugs: bug #61453, want simple, preferably single,...

 
 

bug #61453: want simple, preferably single, step to activate 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 29 May 2025 03:50:55 AM UTC, comment #16: 

comment #14:

> *roff formatters traditionally do not warn if a diversion has been
> collected but never output.  Unless we want to overturn that tradition,


As a clarification, I do not want to overturn that tradition in the general case.  No programming language I've used makes it illegal to define some object but never use it.

The more specific problem this bug faces is that of diversions that the user (or macro package) sets to be triggered under conditions that get short-circuited by using a naïve mechanism to get continuous rendering, such as the one promulgated by the .em example in the manual.  This typically involves a vertical-position trap whose location is specified relative to the page bottom.

Dave <barx>
Group Member
Wed 21 May 2025 08:37:42 PM UTC, comment #15: 

Sorry for misstating various implementation details of -man and -mdoc.

And yes, the previous Summary asked only for a "native mechanism"--though groff effectively had this all along: bug #63587 showed a hack to get INT_MAX, or something approaching it, from within groff before the .R register changed value.

So what this bug is trying to address is not a functionality gap, but an ease-of-use one.  What's lacking is something the user can set at the top to make groff handle all the stuff software should be able to handle.  (".pl \n[.R]u/1v" on its own, for example, will append a couple billion blank lines to the output.  Additional steps are required to subsequently readjust the page length at the end; these additional steps are not straightforward when there are relative-to-page-bottom traps to handle things such as footnotes.  This sort of tedium is what algorithms should handle so humans don't have to.)

So a single request (a special case of .pl, or a new request altogether), or a macro package (which a user can specify on the command line or load via .mso) that provides a one-and-done solution would improve the status quo.

If you think the updated Summary still fails to capture this, let me know and I'll give it another pass.

Dave <barx>
Group Member
Tue 20 May 2025 11:46:26 PM UTC, comment #14: 

Hi Dave,

At 2025-05-20T16:07:41-0400, Dave wrote:

> Follow-up Comment #13, bug #61453 (group groff):
>
> comment #12:
> > The .R register now has the "infinite" semantics,
>
> (since resolution of bug #63587)
>
> > and today I've landed demonstrators of using the infinite
> > page length technique in a full-service macro package to
> > manifest continuous rendering.
>
> This appears to refer to one or both of the commits to resolve bug
> #65190.


Right.  Both.  :)

> By my reading of these commits, this solution is analogous to the .em
> example described in the info manual, except using an empty filename
> rather than .em to detect the document's end.


I think that analogy is a stretched one.

When formatting multiple documents in one groff run, which is a
vanishingly rare case for man but reguarly performed at least twice in
every groff build, to generate "groff-man-pages.pdf" and
"groff-man-pages.utf8.txt", most of the time when the test is evaluated,
we will not be at the end of input.  And that is the only circumstance
under which the end-of-input trap can fire.

> > Is this "native" enough to satisfy this ticket?
> >
> > If not, what more should I be thinking about?
>
> (The below is off the top of my head without running any tests.)
>
> My first concern is that the empty-filename test seems like it
> wouldn't work if groff is run as part of a pipeline (meaning no
> filename is involved at all).  This necessitates the use of .em, which
> bumps up against the first of the drawbacks to the .em technique
> outlined in the original submission.


But this is not so.  When GNU troff's input doesn't have a file name,
the program gives it one.

$ printf 'My file name is \\n[.F].\n' | groff -a
<beginning of page>
My file name is <standard input>.

The `.F` register can only interpolate an empty value when input is no
longer being read, which to the best of my knowledge is only the case
while processing the selected end-of-input macro.

> The second drawback would still seem to apply regardless of which of
> the end-of-input detection methods is used.  -man and -mdoc don't use
> diversions,


They actually do.


$ git grep -Ew '(box|di)' tmac/doc.tmac tmac/mdoc/* tmac/an.tmac
tmac/an.tmac:.  di
tmac/an.tmac:.  di an*paragraph-tag
tmac/an.tmac:.    di an*link-text
tmac/an.tmac:.    di
tmac/doc.tmac:.  \" start enclosure box
tmac/doc.tmac:.  box doc-enclosure-box\n[doc-nesting-level]
tmac/doc.tmac:.  \" finish enclosure box
tmac/doc.tmac:.  box
tmac/doc.tmac:.  chop doc-enclosure-box\n[doc-nesting-level]
tmac/doc.tmac:.  unformat doc-enclosure-box\n[doc-nesting-level]
tmac/doc.tmac:.  nop \*[doc-enclosure-box\n[doc-nesting-level]]\c
tmac/doc.tmac:.\" NS   doc-box-dBla
tmac/doc.tmac:.      \" execute string in a box to get the width of the diversion
tmac/doc.tmac:.      box doc-box-dBla
tmac/doc.tmac:.      box
tmac/doc.tmac:.        \" execute string in a box to get the width of the diversion
tmac/doc.tmac:.        box doc-box-dBla
tmac/doc.tmac:.        box
tmac/doc.tmac:.\" NS doc-item-boxXXX global box
tmac/doc.tmac:.    \" start item box
tmac/doc.tmac:.    box doc-item-box\n[doc-list-depth]
tmac/doc.tmac:.  \" finish item box
tmac/doc.tmac:.  box
tmac/doc.tmac:.  unformat doc-item-box\n[doc-list-depth]
tmac/doc.tmac:.  doc-item-box\n[doc-list-depth]
tmac/doc.tmac:.  \" finish item box
tmac/doc.tmac:.  box
tmac/doc.tmac:.  unformat doc-item-box\n[doc-list-depth]
tmac/doc.tmac:.    doc-item-box\n[doc-list-depth]
tmac/doc.tmac:.    chop doc-item-box\n[doc-list-depth]
tmac/doc.tmac:.    nop \*[doc-item-box\n[doc-list-depth]]\c
tmac/doc.tmac:.  \" finish item box
tmac/doc.tmac:.  box
tmac/doc.tmac:.  unformat doc-item-box\n[doc-list-depth]
tmac/doc.tmac:.  doc-item-box\n[doc-list-depth]
tmac/doc.tmac:.  \" finish (dummy) item box
tmac/doc.tmac:.  box
tmac/doc.tmac:.\" NS   doc-box-dtl
tmac/doc.tmac:.  \" finish item box
tmac/doc.tmac:.  box
tmac/doc.tmac:.  unformat doc-item-box\n[doc-list-depth]
tmac/doc.tmac:.  \" we use a box without '.nf' to compute the tag width (via 'dl' register)
tmac/doc.tmac:.  box doc-box-dtl
tmac/doc.tmac:.  doc-item-box\n[doc-list-depth]
tmac/doc.tmac:.  box
tmac/doc.tmac:.  doc-item-box\n[doc-list-depth]
tmac/doc.tmac:.  \" start function box
tmac/doc.tmac:.  box doc-func-box
tmac/doc.tmac:.  \" finish function box
tmac/doc.tmac:.  box
tmac/doc.tmac:.  chop doc-func-box
tmac/doc.tmac:.  unformat doc-func-box
tmac/doc.tmac:.  nop \*[doc-func-box]\c
tmac/doc.tmac:.\" NS doc-author-nameXXX global box
tmac/doc.tmac:.  \" save to reference box
tmac/doc.tmac:.  box doc-author-name\n[doc-author-count]
tmac/doc.tmac:.\" NS doc-book-name global box
tmac/doc.tmac:.    \" append to reference box
tmac/doc.tmac:.\" NS doc-city-name global box
tmac/doc.tmac:.  \" append to reference box
tmac/doc.tmac:.\" NS doc-date global box
tmac/doc.tmac:.  \" append to reference box
tmac/doc.tmac:.\" NS doc-publisher-name global box
tmac/doc.tmac:.  \" append to reference box
tmac/doc.tmac:.\" NS doc-journal-name global box
tmac/doc.tmac:.  \" append to reference box
tmac/doc.tmac:.\" NS doc-issue-name global box
tmac/doc.tmac:.  \" append to reference box
tmac/doc.tmac:.\" NS doc-optional-string global box
tmac/doc.tmac:.  \" append to reference box
tmac/doc.tmac:.\" NS doc-page-number-string global box
tmac/doc.tmac:.  \" append to reference box
tmac/doc.tmac:.\" NS doc-corporate-name global box
tmac/doc.tmac:.  \" append to reference box
tmac/doc.tmac:.\" NS doc-report-name global box
tmac/doc.tmac:.  \" append to reference box
tmac/doc.tmac:.\" NS doc-reference-title-name global box
tmac/doc.tmac:.\" NS doc-reference-title-name-for-book global box
tmac/doc.tmac:.    \" append to reference box
tmac/doc.tmac:.\" NS doc-url-name global box
tmac/doc.tmac:.\" NS doc-volume-name global box
tmac/doc.tmac:.  \" append to reference box
tmac/doc.tmac:.  \" append to reference box
tmac/doc.tmac:.      \" finish reference box

...but what I think you're saying is that infinite-length documents
need a mechanism and (configurable?) policy for flushing things like
footnotes.  The man page macro packages avoid that concern by not
supporting footnotes.

And I would agree.  Where such mechanisms and policies do not already
exist, we'll need to innovate them.

Something like mm's `Df` register, maybe:

groff_mm(7):
     Df       configures the behavior of DF.  The following values are
              recognized; 4 and 5 do not override the De register (5).

              Value   Effect
              0       Flush pending displays at the end of each section
                      when section‐page numbering is active, otherwise
                      at the end of the document.
              1       Flush a pending display on the current page or
                      column if there is enough space, otherwise at the
                      end of the document.
              2       Flush one pending display at the top of each page
                      or column.
              3       Flush a pending display on the current page or
                      column if there is enough space, otherwise at the
                      top of the next.
              4       Flush as many pending displays as possible in a
                      new page or column.
              5       Fill columns or pages with flushed displays until
                      none remain.

> so these packages are dealing with a simplified version of the
> continuous-rendering problem.

Agreed.

> My ideal world would see a user be able to specify, in principle,
>
> .pl unlimited

We can say that today.  It's spelled '.pl \n[.R]u/1v'.

> at the top of a document, and have the formatter do the right thing
> automatically, handling traps set relative to the page bottom as being
> relative to the end of the document.  This is a lot easier for the
> user than having to specially deal with end of input.

*roff formatters traditionally do not warn if a diversion has been
collected but never output.  Unless we want to overturn that tradition,
I see no problem with entrusting macro packages to take care of this.

> Looking ahead: once such a system has been around long enough to be
> deemed reliable, I expect it would be hard to argue against it being
> made the default for grotty.  The vast majority of terminal users will
> want a continuous page.  But the current architecture provides no
> setting that can be changed to reliably make continuous rendering the
> grotty default.

I haven't contemplated changing the grotty default in this way.  Or, at
least, not that I remember.

> I'm not sure the underlying changes to support this are simple (though
> the last paragraph of comment #11 gives me some hope).  But I've
> opened several wishlist tickets that will require significant
> development time, and I'm not expecting quick action on any of them.
> I don't see any urgency to this request either.

Understood.

I believe that we now have the "native mechanism" for continuous
rendering of which this ticket's Summary speaks, in the sense that we
have a way to defeat pagination.

Can you update the Summary with a better characterization of what we're
now waiting on?

G. Branden Robinson <gbranden>
Group administrator
Tue 20 May 2025 08:07:35 PM UTC, comment #13: 

comment #12:

> The .R register now has the "infinite" semantics,


(since resolution of bug #63587)

> and today I've landed demonstrators of using the infinite
> page length technique in a full-service macro package to
> manifest continuous rendering.


This appears to refer to one or both of the commits to resolve bug #65190.

By my reading of these commits, this solution is analogous to the .em example described in the info manual, except using an empty filename rather than .em to detect the document's end.

> Is this "native" enough to satisfy this ticket?
>
> If not, what more should I be thinking about?


(The below is off the top of my head without running any tests.)

My first concern is that the empty-filename test seems like it wouldn't work if groff is run as part of a pipeline (meaning no filename is involved at all).  This necessitates the use of .em, which bumps up against the first of the drawbacks to the .em technique outlined in the original submission.

The second drawback would still seem to apply regardless of which of the end-of-input detection methods is used.  -man and -mdoc don't use diversions, so these packages are dealing with a simplified version of the continuous-rendering problem.

The third of the drawbacks I believe has been addressed by the .R retooling.

(The drawback mentioned in comment #2 has also been addressed.)



My ideal world would see a user be able to specify, in principle,

.pl unlimited

at the top of a document, and have the formatter do the right thing automatically, handling traps set relative to the page bottom as being relative to the end of the document.  This is a lot easier for the user than having to specially deal with end of input.

Looking ahead: once such a system has been around long enough to be deemed reliable, I expect it would be hard to argue against it being made the default for grotty.  The vast majority of terminal users will want a continuous page.  But the current architecture provides no setting that can be changed to reliably make continuous rendering the grotty default.

I'm not sure the underlying changes to support this are simple (though the last paragraph of comment #11 gives me some hope).  But I've opened several wishlist tickets that will require significant development time, and I'm not expecting quick action on any of them.  I don't see any urgency to this request either.

Dave <barx>
Group Member
Sun 18 May 2025 05:25:01 PM UTC, comment #12: 

Hi Dave,

The .R register now has the "infinite" semantics, and today I've landed demonstrators of using the infinite page length technique in a full-service macro package to manifest continuous rendering.

Is this "native" enough to satisfy this ticket?

If not, what more should I be thinking about?

G. Branden Robinson <gbranden>
Group administrator
Thu 25 Jul 2024 10:34:48 PM UTC, comment #11: 

comment #10:

> comment #7:
> > 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.
>
> There seem to be (at least) two ways to implement this.  When the user specifies ".pl -1", the code can either:
>
> 0 Store -1 as the page length.


I've just foreclosed this possibility (not because of this ticket, but because it was causing me headaches with trapping arithmetic).


commit a00682e9cb4070e35139f6df59130d9ce12505ce
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Jul 25 15:20:55 2024 -0500

    [troff]: Enforce minimum page length.

    * src/roff/troff/div.cpp (page_length): Clamp `pl` request argument to
      the output device's vertical resolution (similarly to the way `ll` and
      `lt` behave).

    * doc/groff.texi.in (Page Layout):
    * NEWS: Document this.


> 0 Set a new flag that indicates page-length handling is to be disregarded.  Any code that compares against page length is made conditional on this flag being unset.


This remains completely feasible.

> In many cases, implementation 1 may automatically do what's desired without further code change.  But this raises your concern about interaction with negative vertical drawing positions.


I have no intention of invalidating negative vertical drawing positions.  Setting the `nl` register to `-1` to force a re-spring of a trap at vertical position 0 is well established.  There are more exotic applications like drawing an arc with its center off the page.
 

> Implementation 2 is a more invasive change.  But because it skips page-length checking altogether, it avoids the prior concern.


Not terribly invasive, I think.  This would be a property of the top-level diversion and no other formatter object I can think of.  That's also the only thing that has page location traps in the first place, so I don't foresee any problems with symbol visibility.  Possibly, all the changes that this feature needs can be made to "div.cpp".

G. Branden Robinson <gbranden>
Group administrator
Sat 20 Jul 2024 02:37:48 AM UTC, comment #10: 

comment #7:

> 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.


There seem to be (at least) two ways to implement this.  When the user specifies ".pl -1", the code can either:

  1. Store -1 as the page length.
  2. Set a new flag that indicates page-length handling is to be disregarded.  Any code that compares against page length is made conditional on this flag being unset.


In many cases, implementation 1 may automatically do what's desired without further code change.  But this raises your concern about interaction with negative vertical drawing positions.

Implementation 2 is a more invasive change.  But because it skips page-length checking altogether, it avoids the prior concern.

Dave <barx>
Group Member
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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-05-21 barx StatusNeed Info None
        Assigned tobarx None
        Summarywant native mechanism for continuous (non-paginated) rendering want simple, preferably single, step to activate continuous (non-paginated) rendering
    2025-05-18 gbranden StatusNone Need Info
        Assigned toNone barx
    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.15-e6e5.
    Corresponding source code