bugGNU roff - Bugs: bug #57618, man/groff_char.7.man: page needs...

 
 

bug #57618: man/groff_char.7.man: page needs an overhaul

Submitter:  Dave <barx>
Submitted:  Fri 17 Jan 2020 08:20:22 AM UTC
   
 
Category:  Core Severity:  2 - Minor
Item Group:  Documentation Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 03 Nov 2020 01:26:21 AM UTC, comment #14: 

comment #8:

> Could I trouble you to file these?


All three filed in one (for now, until a specific direction is clearer) bug report, bug #59402.

Dave <barx>
Group Member
Mon 26 Oct 2020 01:59:46 PM UTC, comment #13: 

LGTM.

Dave <barx>
Group Member
Thu 22 Oct 2020 10:23:39 AM UTC, comment #12: 

Even more fixed in e3bf6b74d60d8e536dd3a17e893312a5c82efd39.

Right? :P

G. Branden Robinson <gbranden>
Group administrator
Fri 16 Oct 2020 10:10:15 PM UTC, comment #11: 

comment #8:

> This sounds like a bug in (1) preconv for not emitting
> composite Unicode glyph escapes and (2) troff for failing to
> accept them--but that would require more state tracking.  Maybe
> we could add a heuristic into troff with a hard-coded table of
> combining characters so we can tell the user to put the input
> \[uXXXX_YYYY] form.  There's already a big table for detecting
> invalid UTF-8 sequences, so it could probably fit in there.
> I'll see what I think after actually looking again at the code.
>
> I note regarding point (1) that if we implement my proposal in
> bug #58796, the frequency with which such things will have to be
> emitted will drop off precipitously.
>
> And (3) I reckon we need to clarify what we mean by "NFD".
> We mean "decomposed and expressed as composite Unicode special
> character escapes" (whew!).
>
> Could I trouble you to file these?


You know me, any excuse to file new bug reports.

But if (2) is a legitimate bug, I'm not sure (1) is: if troff accepts whatever form is thrown at it, it shouldn't matter which form preconv emits.  (Vice versa is less true, since users can always directly embed \[uNNNN] escapes directly in their source, meaning troff should be equally conversant with "\[u006F_0308]" and "o\[u0308]", unless we specifically document that the latter is disallowed.)

And (3) seems dependent on where the discussion of comment #10 goes.

So I reckon for now I'll deny myself the satisfaction of opening new bug reports till I get a better handle on what they should be reporting.

Dave <barx>
Group Member
Tue 13 Oct 2020 09:24:26 AM UTC, comment #10: 

comment #9:

> commit 1455bf9af0bd401bec52c4223dbf701152d96935
> Author: G. Branden Robinson <g.branden.robinson@gmail.com>
> Date:   Fri Oct 9 01:40:46 2020 +1100
>
>     groff_char(7): Clarify NFD discussion.
>    
>     Clarify that GNU troff (the formatter) requires Unicode special
>     character escapes to be in Normalization Form D.  Give examples of 3
>     ways that work to input "café", and one that doesn't, using a
>     non-NFD-compliant Unicode special character escape.


But the example that doesn't work doesn't on a technicality.  It's true groff doesn't recognize “caf\[u00e9]”, but it recognizes "caf\[u00E9]" just fine.  And this is NFC form.  (And what preconv emits from Latin-1 input.)  Groff just doesn't seem to be as NF-strict as this passage makes it out to be.

Dave <barx>
Group Member
Thu 08 Oct 2020 03:28:10 PM UTC, comment #9: 

Fixed in several recent commits.


commit 7f0a617b4082f74c24bb491c9ad6b78ef93fc61b
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Oct 9 02:04:14 2020 +1100

    groff_char(7): Fix style nit.

    Cancel hyphenation of adverbially enhanced attributive phrase.

    Thanks again to Dave Kemper for his Strunky White counsel.

    Fixes item #6 in Savannah #57618.

commit 5fb8bb1be57255c9a5dded653c37a134b7de5b94
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Oct 9 01:59:47 2020 +1100

    groff_char(7): Lean less on "note that" crutch.

    Thanks to Dave Kemper for his Strunky White counsel.

    Fixes item #5 in Savannah #57618.

commit 1bcec204a165dccc2b2738f880f1490d4a528d3d
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Oct 9 01:50:40 2020 +1100

    groff_char(7): Clarify discussion of NBSP and SHY.

    Mention @g@troff instead of groff since formatter behavior is
    specifically at issue.

    Thanks to Dave Kemper for the discussion.

    Fixes item #4 in Savannah #57618.

commit 1455bf9af0bd401bec52c4223dbf701152d96935
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Oct 9 01:40:46 2020 +1100

    groff_char(7): Clarify NFD discussion.

    Clarify that GNU troff (the formatter) requires Unicode special
    character escapes to be in Normalization Form D.  Give examples of 3
    ways that work to input "café", and one that doesn't, using a
    non-NFD-compliant Unicode special character escape.

    Thanks to Dave Kemper for the discussion.

    Fixes item #3 in Savannah #57618.

commit e5eb39075afa1b9c85a303581c963309f7f903fe
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Oct 9 01:21:37 2020 +1100

    groff_char(7): Fix style nit.

    Stop manually suppressing hyphenation of "Latin-1" and "UTF-8"; it is
    unnecessary because numerals do not have hyphenation codes by default,
    so these words will not hyphenate even with the explicit hyphen present.

    Thanks to Dave Kemper for catching this.

    Fixes item #2 in Savannah #57618.

commit 261394050e4f887963a63d7ec394bf5b5b282fa2
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Oct 9 01:16:03 2020 +1100

    groff_char(7): Fit Latin-1 table into 78 columns.

    ...for real this time.  It was still overrunning on the "ascii" output
    device, thanks to the substitutions of the 3-cell "(C)" and "(R)" for
    © and ®, respectively.

    Drop "congruent to" from notation of \[=~]; it just won't fit, and I
    don't want to go back to using abbreviations in the descriptions.

    Remove XXX comments about tables overrunning 78n, because, thanks to the
    elimination of the AGL column in the previous commit to this file and
    the change above, they no longer do.

commit bf104009d082fe932bb25ce8936f5a3a781e7ac9
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Oct 9 01:02:55 2020 +1100

    groff_char(7): Remove AGL column from tables.

    Also drop references to Adobe Glyph List in text.

    Fixes item #1 in Savannah #57618.


G. Branden Robinson <gbranden>
Group administrator
Thu 08 Oct 2020 01:37:51 PM UTC, comment #8: 

comment #7:

> It looks like most if not all the problems Branden identified in comment #1 have been addressed.  The page looks great now!


Thanks!  It was quite a bit of work.
 

> But of course I still have complaints.
>
> (I realize this man page is very much a work in progress, so some of the below observations may be addressed in changes that have yet to be committed.)


Nope, at the time you made this comment I was taking a break I felt I had earned from the page.  :)

> AGL
>
> I still advocate for removing the AGL (formerly PostScript) column.  In addition to the reasons I previously gave: with this man page now having a convenient link to the AGL, and with both documents including the Unicode value for every entry, that value becomes an easy cross-reference for those very few users who do need to look up an Adobe name.
>
> If the column is retained, something on the page should tell users what they can do with this information.
>
> What are the arguments for moving this information to grops(1) (as proposed in comment #5) instead of removing it altogether?


I have none.

> hyphenation-inhibition overkill
>
> While no harm arises from putting \% in front of things like "Latin-1" and "UTF-8," they accomplish nothing: groff already won't break a line at a hyphen with only numbers on one side of it.


Good point.  I'll fix this.

> intro text
>
> In most subsections, if there is text before the table, it gives an overview of that section or the data tabulated in the following table.  But a couple of sections (e.g., "Supplementary Latin letters," "Logical symbols") lead off with minutiae that might be better placed below the table rather than above it.


I considered this, but I prefer the consistency of not having trailing text after any table (in this page).

> NFD
>
> (section "Special character escape forms"): "groff requires NFD (Normalization Form D)"
>
> In what sense is this true?


That's a good question.  I pretty much just took Werner's word on faith.  :)

https://lists.gnu.org/archive/html/bug-groff/2020-08/msg00016.html

> Groff doesn't take Unicode input directly at all, but it does take Latin-1, the bulk of which's character set consists of precomposed characters that in Unicode would be considered NFC.
>
> And for Unicode input passed through preconv, groff seems happy with NFC but not with NFD:
>


> $ printf "co\xF6perate\n" | uconv -f latin1 -x Any-NFC | groff -Kutf8 > /dev/null
> $ printf "co\xF6perate\n" | uconv -f latin1 -x Any-NFD | groff -Kutf8 > /dev/null
> <standard input>:1: warning: can't find special character `u0308'
> $


>
> groff does handle composed characters given in \[uNNNN_NNNN] form:
>


> $ echo 'co\[u006F_0308]perate' | groff > /dev/null
> $


>
> but this is not what preconv emits.


This sounds like a bug in (1) preconv for not emitting composite Unicode glyph escapes and (2) troff for failing to accept them--but that would require more state tracking.  Maybe we could add a heuristic into troff with a hard-coded table of combining characters so we can tell the user to put the input \[uXXXX_YYYY] form.  There's already a big table for detecting invalid UTF-8 sequences, so it could probably fit in there.  I'll see what I think after actually looking again at the code.

I note regarding point (1) that if we implement my proposal in bug #58796, the frequency with which such things will have to be emitted will drop off precipitously.

And (3) I reckon we need to clarify what we mean by "NFD".  We mean "decomposed and expressed as composite Unicode special character escapes" (whew!).

Could I trouble you to file these?

> non-printing characters
>
> The text refers to NBSP and SHY as "non-printing characters," but this doesn't seem to be how they are classified (if ISO_8859-1(7) and Perl's Unicode library are to be believed):
>


> $ perl -e '$_ = "\N{NO-BREAK SPACE}\N{SOFT HYPHEN}"; s/[[:print:]]/X/g; print "$_\n"'
> XX
> $


This one's an easier fix.  I meant "non-printing" to groff, and I will update the page accordingly.

> verbiage
>
> (section "Rules and lines"): "Note that both the AGL and the Unicode-derived names of these three glyphs are rough approximations."
>
> 0 ...as opposed to precise approximations?
> 0 The phrase "Note that..." communicates nothing.  Just tell the reader the thing you want her to note, and she will note it.


Yes.  Although you'll find it frequently in my commit messages in a different sense, as "I added a note to the effect that", but in the imperative mode as should be done for commit messages and change logs.

But yeah, this is a fair point which applies to lots of groff documentation.  I'll always think of it as "the Dave Kemper edit" from now on.

> hyphens
>
> "Frequently-used glyphs" should have no hyphen.


Fair.

> "Playing card symbols" should arguably have one.


Disagree here.  Playing card symbols are like ice cream cones.

Thanks for your close review.  I felt shame regarding the old groff_char(7) man page.  Now it almost looks like something we can be proud of.  :D

Here's the checklist for closing this ticket, then.  Any further problems can go into a new report.

1. Remove AGL column.
2. Stop suppressing breaks in Latin-1, UTF-8, etc.
3. Note that maximal decomposition isn't necessary if a glyph name special character escape is used.  Something like that.  You can't tell GNU troff to "co\xF6perate", but you can tell it to co\[:o]perate or co\[o ad]perate.
4. Clarify context of non-printability WRT NBSP and SHY.
5. Un-"note that" and smooth approximations.
6. "Frequently used".

G. Branden Robinson <gbranden>
Group administrator
Tue 22 Sep 2020 01:05:41 AM UTC, comment #7: 

It looks like most if not all the problems Branden identified in comment #1 have been addressed.  The page looks great now!

But of course I still have complaints.

(I realize this man page is very much a work in progress, so some of the below observations may be addressed in changes that have yet to be committed.)




AGL

I still advocate for removing the AGL (formerly PostScript) column.  In addition to the reasons I previously gave: with this man page now having a convenient link to the AGL, and with both documents including the Unicode value for every entry, that value becomes an easy cross-reference for those very few users who do need to look up an Adobe name.

If the column is retained, something on the page should tell users what they can do with this information.

What are the arguments for moving this information to grops(1) (as proposed in comment #5) instead of removing it altogether?





hyphenation-inhibition overkill

While no harm arises from putting \% in front of things like "Latin-1" and "UTF-8," they accomplish nothing: groff already won't break a line at a hyphen with only numbers on one side of it.





intro text

In most subsections, if there is text before the table, it gives an overview of that section or the data tabulated in the following table.  But a couple of sections (e.g., "Supplementary Latin letters," "Logical symbols") lead off with minutiae that might be better placed below the table rather than above it.





NFD

(section "Special character escape forms"): "groff requires NFD (Normalization Form D)"

In what sense is this true?  Groff doesn't take Unicode input directly at all, but it does take Latin-1, the bulk of which's character set consists of precomposed characters that in Unicode would be considered NFC.

And for Unicode input passed through preconv, groff seems happy with NFC but not with NFD:


$ printf "co\xF6perate\n" | uconv -f latin1 -x Any-NFC | groff -Kutf8 > /dev/null
$ printf "co\xF6perate\n" | uconv -f latin1 -x Any-NFD | groff -Kutf8 > /dev/null
<standard input>:1: warning: can't find special character `u0308'
$


groff does handle composed characters given in \[uNNNN_NNNN] form:


$ echo 'co\[u006F_0308]perate' | groff > /dev/null
$


but this is not what preconv emits.




non-printing characters

The text refers to NBSP and SHY as "non-printing characters," but this doesn't seem to be how they are classified (if ISO_8859-1(7) and Perl's Unicode library are to be believed):


$ perl -e '$_ = "\N{NO-BREAK SPACE}\N{SOFT HYPHEN}"; s/[[:print:]]/X/g; print "$_\n"'
XX
$





verbiage

(section "Rules and lines"): "Note that both the AGL and the Unicode-derived names of these three glyphs are rough approximations."

  1. ...as opposed to precise approximations?
  2. The phrase "Note that..." communicates nothing.  Just tell the reader the thing you want her to note, and she will note it.





hyphens

"Frequently-used glyphs" should have no hyphen.

"Playing card symbols" should arguably have one.

Dave <barx>
Group Member
Sat 18 Jan 2020 03:36:22 PM UTC, comment #6: 

Reconsidering the matter after reading Dave's comment #4, he is probably right that his arguments are stronger than those i brought forward, so i don't insist on keeping the PostScript column.

I don't think that the glyph list should be moved out of the groff_char(7) manual page, though.  As i see it, the whole point of that manual page is providing that glyph list; the rest of the text in that page are merely explanatory notes on the glyph list that would hang in limbo if the list itself were moved elsewhere.

Also, i'm not sure the grops(1) manual needs a list of glyph names.  The grops(1) manual explains how the grops utility works in general and individual glyphs are somewhat tangential to that topic.  Also, glyph naming appears to depend on the individual font (even though it seems everybody encourages using standard names for glyphs whenever possible).  So maybe pointing to something like https://github.com/adobe-type-tools/agl-aglfn/blob/master/aglfn.txt moght be more useful than maintaining our own copy?  I'm not sure, though.  Also, this may be drifting off-topic from what this ticket is about.

Ingo Schwarze <schwarze>
Group Member
Sat 18 Jan 2020 04:16:54 AM UTC, comment #5: 

Other things being equal, I lean toward getting rid of the PostScript column or, more precisely, moving it to the grops(1) page.  (I'd have gropdf(1) just direct the reader to grops(1) for the glyph list with PostScript names.  Now's the time to tell me if/how PDF glyph names are incompatible with, or extend, PostScript names.)

The main thing stopping me at this point is the DRY principle.  The groff glyph list should probably maintained external to both pages and inlined into each, with columns appropriate to the page.

But that would mean that groff_char.7.man and grops.1.man need to become .in files, and bleah.

A bit of tedium.  But not insuperable.

G. Branden Robinson <gbranden>
Group administrator
Fri 17 Jan 2020 09:12:49 PM UTC, comment #4: 

I concede the good points made on the usefulness of 80-column limits and the uselessness of the "sic"s.  But I must confess I don't find either of these points particularly compelling:

comment #3:

> I consider the PostScript column useful for two reasons: it
> provides a nice reminder that while almost every character can
> be expressed in terms of Unicode, not every system of glyphs
> is a subset of Unicode nor necessarily organized in a strictly
> numeric manner.  Also, PostScript plays a special role in the
> history of roff, and some aspects of the roff character system -
> like the distinction of \- and \(mi - can be better understood
> when considering PostScript output than when considering Unicode.


The first reason, especially, seems more philosophical than practical in the context of someone merely trying to use the language -- and also redundant, considering roff's own character names are largely neither numeric nor Unicode-derived.  The second point carries a bit more weight, but -- again, as a practical matter to users in 2020 and beyond, who only need to create documents and for whom the origin of certain roff-isms is merely a tangent -- probably not enough to justify the column's retention.

Additionally, the man page itself does nothing to explain why the column is there or what a user could do with its information, the likeliest outcome of which -- for readers who don't gloss over the column entirely -- is to make them wonder, "What am I missing here?"

I'm not opposed to the PostScript column, just not sure I see its need in the modern roff ecosystem, especially if its presence requires other contortions to keep tables within 80 TTY columns.  Further down the page, for example, just about every entry in the Notes column of the Brackets table spans two lines, while many could easily fit on one (and look much nicer) if the PostScript column went away.

Dave <barx>
Group Member
Fri 17 Jan 2020 01:46:44 PM UTC, comment #3: 

Eliminating the "sic"s was just fine, i think.  When a manual page quotes a syntax element, users should assume that there is no typo.  If a name is really too badly misleading, causing a risk of users misusing the feature, than a mere "sic" is not enough, but a warning needs to be given in a complete, easily understandable sentence - see the last two paragraphs of the DESCRIPTION of https://man.openbsd.org/man3/SSL_CTX_use_certificate.3 (regarding SSL_CTX_check_private_key(3)) for a drastic example.  In the case at hand, there is no risk because users are unlikely to type in the PostScript glyph name.  And even if they do so and get the spelling wrong because they don't want any seabirds in their document, there won't be any dire consequences.  Manual pages should remain concise, focussing on their own topic, and refrain from picking apart unrelated weaknesses in other software.

I consider the PostScript column useful for two reasons: it provides a nice reminder that while almost every character can be expressed in terms of Unicode, not every system of glyphs is a subset of Unicode nor necessarily organized in a strictly numeric manner.  Also, PostScript plays a special role in the history of roff, and some aspects of the roff character system - like the distinction of \- and \(mi - can be better understood when considering PostScript output than when considering Unicode.

As a minor detail, i agree that a description as "left-pointing guillemet" would be better than "left guillemet".

Branden, your todo list looks good to me, so please do use this ticket for that purpose.

Regarding table width, you can shorten "Output" to "Out" and the column width to 3n, and you can reduce inter-column spacing from 3 to 1.  That probably isn't sufficient for all lines, but for most.  Maybe some Notes can be made more concise, but in cases of possible doubt, i'd prioritize precision over nice layout.

Also note how mandoc(1) deals with lines of excessive length (showing an extract from the groff to mandoc diff here, compressing whitespace such that it becomes intelligible in this web interface):

- i \[.i] dotlessi u0131 i without a dot (Turkish)
+ i \[.i] dotlessi u0131 i without a dot
+                        (Turkish)

I.e. mandoc puts multiple text lines into single table cells when needed, making sure that it stays inside the page width specified by the user (or the default of 78).

I think the 80 column limit is still very relevant.  It is still very widespread in coding styles, so many programmers use 80-column virtual terminals (and that's an important audience for groff).  Also, the markup of practically all manual pages i'm aware of is optimized such that it looks good in 80-column terminals.   Finally, some argue that shorter lines are easier to follow when reading; consider printed newspapers, for example, so optimizing for something like 200-character lines may not be a bright idea regardless of the century.

Ingo Schwarze <schwarze>
Group Member
Fri 17 Jan 2020 09:51:09 AM UTC, comment #2: 

comment #1:

> I already got rid of the 4 "sic"s.


Well.  Serves me right for not doing a "git pull" before submitting this.

I'm not sure eliminating the "sic"s entirely is the right answer, though: PostScript does use the wrong term, and the man page should let readers know that this wrong term is not a typo on the man page.

A more interesting question is whether the PostScript column adds any value at all.  Even roff code targeting -Tps output would very rarely use a PostScript name for a glyph--perhaps rarely enough that it's inappropriate to have it in a quick-reference guide for groff characters.

> But the page still has much that ails it, as you note.


I don't recall noting any such thing...but sure, I'll take credit for it!

> There is a theory that the [sic] was not for the guillemot/met spelling,
> but due to the problematic terminology of "left" and "right", because
> these glyphs are supposed to mirror-reflect when used in RTL languages.


This was my brief conjecture (I don't know that it rises to the level of a theory) in bug #57546's discussion, but Werner, who originally added the "sic"s, quickly squelched it by clarifying his intended meaning.

> So I guess "forward" (in the direction of text flow) and
> "backward" are about the only terms we can use.


...except, as Werner also points out in that thread, even some languages that have the same text-flow direction use the guillemets in opposite senses.  "left-pointing" and "right-pointing" seem the only truly semantic-neutral descriptors.

Dave <barx>
Group Member
Fri 17 Jan 2020 09:08:30 AM UTC, comment #1: 


commit 9fd6d7b45d9bb19c9bc3348cbe703c64a662b020
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Jan 16 17:14:49 2020 +1100

    groff_char(7): Fix typos in glyph descriptions.

    ...and a bogus "sic".  A "guillemet" is in fact a kind of quotation
    mark.  Adobe got it wrong with "guillemot", which is a seabird.


I already got rid of the 4 "sic"s.

But the page still has much that ails it, as you note.

  • The stuff in the first paragraph about "(N/A)" for unavailable glyphs is a lie, as far as I can tell.


  • As you note, the tables are often too wide.  It would be nice to get them fitting on an 80-column terminal.  This often means getting them to fit on a U.S. letter page when typeset, too, so it's a good norm to observe.


  • Way too much emphasis on Latin-1.  We use preconv now.  IMO groff input should be pure ASCII plus groff escapes, but preconv gives us more flexibility than that.


  • In fact I'd nuke the Latin-1 section altogether.  It's an old, uninteresting encoding, and people had switched away to ISO 8859-15 even before they went to full-on UTF-8, because they needed the Euro sign.


  • Lots of Bernd-isms in this page, like repeatedly putting noun phrases in italics.


I'd have fixed this page long ago if it didn't require so much work.

But fixing the irritating typos was a start.

There is a theory that the [sic] was not for the guillemot/met spelling, but due to the problematic terminology of "left" and "right", because these glyphs are supposed to mirror-reflect when used in RTL languages.  So I guess "forward" (in the direction of text flow) and "backward" are about the only terms we can use.

But does groff even support RTL languages at all?  As far as I know it does not, and this left/right is not worth fixing, in my view, until and unless it does.

I am therefore, instead of closing this bug, adapting it to my own foul purposes.  The laundry list of things I think it needs is above.

Comments are welcome on my proposed actions.

G. Branden Robinson <gbranden>
Group administrator
Fri 17 Jan 2020 08:20:22 AM UTC, original submission:  

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

Dave <barx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by schwarze (Posted a comment)
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-08 gbranden StatusConfirmed Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2020-10-08 gbranden CategoryNone Core
    2020-01-17 schwarze Severity3 - Normal 2 - Minor
    2020-01-17 gbranden StatusNone Confirmed
        Assigned toNone gbranden
        Summaryman/groff_char.7.man: meaning of &quot;[sic]&quot; is unclear man/groff_char.7.man: page needs an overhaul

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code