bug-groff
[Top][All Lists]
Advanced

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

[bug #57618] man/groff_char.7.man: meaning of "[sic]" is unclear


From: Dave
Subject: [bug #57618] man/groff_char.7.man: meaning of "[sic]" is unclear
Date: Fri, 17 Jan 2020 03:20:23 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0

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

                 Summary: man/groff_char.7.man: meaning of "[sic]" is unclear
                 Project: GNU troff
            Submitted by: barx
            Submitted on: Fri 17 Jan 2020 02:20:22 AM CST
                Category: None
                Severity: 3 - Normal
              Item Group: Documentation
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

groff_char(1) has "[sic]" in four places: twice in the latin1 table and twice
in the Quotes table.  In both tables, the "[sic]" is in the Notes column, but
_bug #57546 comment #4 <http://savannah.gnu.org/bugs/?57546#comment4>_
clarifies that it's intended to apply to the PostScript column.  Thus its
present placement obscures its meaning.

For TTY output, the latin1 table already runs to 89 columns, which is more
than is ideal.  But only about a dozen of its 94 rows exceeds the 80-column
mark, so it still looks mostly OK in an 80-column window.

Moving the "[sic]" from the Notes column to the PostScript column, where its
meaning is much clearer, pushes the table to 95 columns, and more than doubles
the number of lines that overflow an 80-column window (with most of these in
the top quarter of the table, making them especially noticeable).

So, net result of this change: clearer semantics, uglier presentation.

The Quotes table currently stands at exactly 80 columns, and expands to 86
with the same edit.  Not as bad, but still suboptimal.

Still, hardly anyone's display is limited to 80 columns anymore (or, it's on a
pocket-sized screen and limited to much less than 80 columns), so maybe that
arbitrary constraint is no longer important.

Or maybe someone will think of a clever way to improve the semantic clarity
that doesn't result in widening the whole table.




    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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