Follow-up Comment #14, bug #61453 (group groff): Hi Dave,
At 2025-05-20T16:07:41-0400, Dave wrote:
> Follow-up Comment #13, bug #61453 (group groff):
>
> [comment #12 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?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?61453>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
