[bug #64440] [docs] minor corrections and updates

[G. Branden Robinson]

Update of bug #64440 (project groff):

                  Status:                    None => In Progress            
             Assigned to:                    None => gbranden               
                 Summary: Minor documentation updates => [docs] minor
corrections and updates

    _______________________________________________________

Follow-up Comment #1:


[comment #0 original submission:]
> 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.

Cool, thanks!

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

I think I'll use some form of the word "isolated", because my brain turns into
a pretzel if I try to adopt this...consensus interpretation of widows and
orphans.

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

The excitement's not done here.  The unit _is_ twelfths of an em after all!

...for _nroff_ mode devices.

Since (I feel that) I have to document that _and_ the CSTR #54 erratum, it's a
good thing I can get rid of the erroneous claim that the \n[.ss] and \n[.sss]
register values are rounded on terminal devices.  They are not.  But
horizontal motion quanta apply as they always do, a fact which can be taken
for granted at this point in the manual's presentation.

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

That's pretty conversational in tone, which sometimes draws criticism, but
I'll see what I can come up with.


    _______________________________________________________

Reply to this item at:

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

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