bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #65190] [man, mdoc] revise implementation of continuous rendering m


From: G. Branden Robinson
Subject: [bug #65190] [man, mdoc] revise implementation of continuous rendering mode
Date: Mon, 22 Jan 2024 15:25:59 -0500 (EST)

URL:
  <https://savannah.gnu.org/bugs/?65190>

                 Summary: [man,mdoc] revise implementation of continuous
rendering mode
                   Group: GNU roff
               Submitter: gbranden
               Submitted: Mon 22 Jan 2024 08:25:59 PM UTC
                Category: Macro - others/general
                Severity: 3 - Normal
              Item Group: Incorrect behaviour
                  Status: Confirmed
                 Privacy: Public
             Assigned to: gbranden
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Mon 22 Jan 2024 08:25:59 PM UTC By: G. Branden Robinson <gbranden>
The present approach leads to issues like bug #65189, because it's impossible
for the macro package to know how long a _tbl_ table will be before formatting
it.

At present, continuous rendering is handled by accepting the default page
length, and then incrementally growing it as the formatter gets "close" to the
page bottom, by setting a trap.

This has been a fragile procedure and I fixed several bugs in it for _groff_
1.23.0 so that we could get better results when support rendering hundreds of
man page documents in one formatter run.

But bug #65189 seems intractable by the foregoing trapping/page-length
incrementation approach.  Our trap for breaking the page body before the
footer doesn't seem go off inside _tbl_ tables, I think because they are
formatted in diversions by default.  (I tried to tell _tbl_ not to use keeps
when continuously rendering, but it didn't help cases like _lsp-help_(1) and
_ascii_(7)).  (The problem may be that text blocks are formatted in diversions
no matter what.)

What appears to happen is that output sneaks across a page boundary (as the
formatter conceives it) anyway.  This has a couple of negative consequences.

1.  Vertical rules, drawn upward from the table bottom, can show up in the
wrong place; this is bug #65189.
2.  Warnings in the "break" category have long been pretty useless with
continuously formatted man pages.  Because the page length is variable, the
reported page number means nothing.

Here's a reproducer.


$ cat ATTIC/line-too-long.man
.pl 10v \" contrive an artifically short page length
.TH foo 1 2024-01-22 "groff test suite"
.SH Name
foo \- bar
.SH Description
.TS
L.
T{
.nf
1
2
3
4
5
6
T}
T{
.nf
1
2
3
4
5
6
T}
.TE
.P
12345678901234567890123456789012345678901234567890123456789012345678901234567890


We get the following warning.


troff:ATTIC/line-too-long.man:28: warning [page 2, line 7]: cannot break line


...which has no relationship to any reality the user can perceive.


$ nroff -t -rLL=65n -man ATTIC/line-too-long.man | cat -n
troff:ATTIC/line-too-long.man:28: warning [page 2, line 7]: cannot break line
     1  foo(1)               General Commands Manual               foo(1)
     2
     3  Name
     4       foo - bar
     5
     6  Description
     7       1
     8       2
     9       3
    10       4
    11       5
    12       6
    13       1
    14       2
    15       3
    16       4
    17       5
    18       6
    19
    20      
12345678901234567890123456789012345678901234567890123456789012345678901234567890
    21
    22  groff test suite            2024‐01‐22                     foo(1)


Line 7 of what?  Where?

If the page length were unbounded (or practically so), we could radically
simplify the implementation of continuous rendering mode, _and_ fix the
foregoing problems.

So what we want to do is the moral equivalent of `.pl INT_MAX`.  But thereby
hangs a tale...







    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65190>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]