bug-groff
[Top][All Lists]
Advanced

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

[bug #64440] Minor documentation updates


From: Dave
Subject: [bug #64440] Minor documentation updates
Date: Tue, 18 Jul 2023 01:40:33 -0400 (EDT)

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

                 Summary: Minor documentation updates
                   Group: GNU roff
               Submitter: barx
               Submitted: Tue 18 Jul 2023 12:40:31 AM CDT
                Category: Core
                Severity: 1 - Wish
              Item Group: Documentation
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Tue 18 Jul 2023 12:40:31 AM CDT By: Dave <barx>
This bug documents three minor documentation issues in the info manual.  These
are unrelated to each other, but not worthy of their own bug reports, so I'm
collecting them here.

1. Consensus on the email list (see thread starting at
http://lists.gnu.org/r/groff/2023-06/msg00116.html) is that "widow" generally
refers to a single line of a paragraph at the top of a page.  The manual
currently talks about "preventing [a paragraph's] first line from being
widowed at the page bottom," a situation that the document elsewhere terms an
orphan.
2. After a few messages back and forth with some wrong turns, Branden and I
concluded (http://lists.gnu.org/r/groff/2023-05/msg00103.html) that CSTR #54
misstated the units AT&T troff (as empirically determined on DWB 3.3 troff)
used for the .ss request, and he stated an intention to document this.
3. A sentence in the .sp section reads: "If invoked with the no-break control
character, @code{sp} moves the pending output line's text baseline by
@var{distance}."

This is accurate, but might it be ambiguous?  When I read it, my
interpretation was that it moved the baseline from the point in the pending
line at which the 'sp was invoked (a la the \v escape) rather than moving the
baseline of the entire line.

Maybe that's just me.  But if others agree that's a valid reading of that
sentence, it should be clarified (maybe by inserting "entire" before
"pending"?).

The way Branden explained it on the email list a few months ago
(http://lists.gnu.org/r/groff/2023-05/msg00031.html) also seems unambiguous:
"the position of the text baseline is one of those properties of the output
line that is not determined until the line has been broken.  And what the `sp`
request really does is decide where your next text baseline is going to be."







    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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