bug-groff
[Top][All Lists]
Advanced

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

[bug #55124] doc/groff.texi: text about negative .pl values needs clarif


From: Dave
Subject: [bug #55124] doc/groff.texi: text about negative .pl values needs clarification
Date: Wed, 28 Nov 2018 10:13:32 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0

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

                 Summary: doc/groff.texi: text about negative .pl values needs
clarification
                 Project: GNU troff
            Submitted by: barx
            Submitted on: Wed 28 Nov 2018 09:13:30 AM CST
                Category: Core
                Severity: 3 - Normal
              Item Group: Documentation
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

Part of the .pl section of the info manual states:

Negative @code{pl} values are possible also, but not very useful: No trap is
sprung, and each line is output on a single page

This contains a couple of ambiguities:

(1) "No trap is sprung": This wording makes it sound like this is referring to
a specific trap; otherwise, it would say "no traps are sprung," or "no traps
of type (x) are sprung."  But no specific trap is mentioned in this section. 
The paragraph before refers to traps in a general sense for setting top and
bottom margins; these are usually page-location traps, which indeed are not
sprung with negative .pl values.  But input line traps, for example, _are_
sprung.  I haven't comprehensively tested which types of traps are sprung and
which aren't, so I don't yet have a suggested replacement wording.

(2) "each line is output on a single page": This could be read two different
ways: all output is on a single, unending page; or each line of output starts
a new page.  The second is what actually happens (which is an odd choice, as
the first would be useful for TTY output, while it's hard to imagine a
real-world use for the second--a fact the documentation even acknowledges by
calling the behavior "not very useful"), so the wording should say this more
unambiguously.




    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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