bugGNU roff - Bugs: bug #63028, document nroff \o limitations in...


bug #63028: document nroff \o limitations in modern terminal emulators

Submitter:  Dave <barx>
Submitted:  Wed 07 Sep 2022 04:32:56 PM UTC
Category:  Driver - others/general Severity:  1 - Wish
Item Group:  Documentation Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Fri 19 Apr 2024 10:33:18 AM UTC, comment #5: 

original submission:

> they should think about the order in which they specify the
> characters, as only the last one is likely to end up visible.

An exception is (at least some) space-like characters.

$ echo "\o'abcd'efg" | nroff | cat -s

$ echo "\o'abc\0'efg" | nroff | cat -s

$ echo "\o'abc\ 'efg" | nroff | cat -s

Groff and Heirloom's nroff produce identical results with those inputs.  Where they diverge is when \o is given an ordinary space:

$ echo "\o'abc 'efg" | nroff | cat -s
troff:<standard input>:1: error: expected ordinary or special character, got a space

Heirloom nroff's output is the same, but it doesn't throw the error.  If that holds of ancestor nroffs as well, groff objecting to this formerly permitted construction should be documented in groff_diff(7).

Dave <barx>
Group Member
Mon 07 Aug 2023 06:37:21 PM UTC, comment #4: 

The comment #3 side issue is now bug #64526.

Dave <barx>
Group Member
Mon 26 Jun 2023 04:46:21 PM UTC, comment #3: 

original submission:

> (And maybe (3) that if they want to use \o for accented
> characters, there are more robust ways to achieve that.)

Nowadays, most of groff's Texinfo examples try to exhibit groff best practices, but the manual does have an example (polished by bug #63002) that uses \o to produce an accented character.

A caf\o
in Paris
    @result{} A cafĂ© in Paris

Despite this not being a good way in general to place diacritics on characters (it's particularly ill suited to the letter i, which must shed its dot when it acquires a diacritic), the advantage to using it in an example that many readers will view on a terminal is that a terminal can give meaningful output for it (albeit not through the \o mechanism but by using the appropriate precomposed character).  This would not be the case with an example that actually requires the overstrike to do its job, such as this style-nerdy one:

\[lq]I'm torn between US and UK punctuation styles\o
she lamented.

However, taking context into account: this example isn't even trying to illustrate the \o escape, but groff's ability to use newlines as escape-sequence delimiters.  So maybe a different escape altogether would do this job without the side effect of choosing between best-practice groff code and terminal-displayable output (notwithstanding the fact that using newlines as delimiters is certainly not a best practice itself.  But at least that is discouraged in the very next sentence.  There's no comment on the overstriking-to-apply-diacritics aspect of the example--and such a warning would be out of place here, since the use of \o is not the point of this section).

I don't have a suggestion offhand of a better escape for this; I'd need to peruse the list of escapes that accept newlines as delimiters and choose one that can produce output that would render well on a terminal.

Dave <barx>
Group Member
Fri 07 Oct 2022 10:51:59 PM UTC, comment #2: 

True and then some: unlike grotty, which outputs overstruck characters that terminals probably won't render, grohtml appears to output only the final character of an \o sequence.

$ printf '\o"x+o"\n' | groff -Thtml | grep -o '<p>.*</p>' | od -c
0000000   <   p   >   o   <   /   p   >  \n

Dave <barx>
Group Member
Fri 07 Oct 2022 12:59:17 AM UTC, comment #1: 

Lack of true overstriking will also afflict HTML output.

G. Branden Robinson <gbranden>
Group administrator
Wed 07 Sep 2022 04:32:56 PM UTC, original submission:  

Bug #62983 has been Postponed, but in the meantime, the documentation could be updated to warn nroff users that (1) few (no?) modern terminal emulators support overstruck characters, and (2) if they must use \o, they should think about the order in which they specify the characters, as only the last one is likely to end up visible.  (And maybe (3) that if they want to use \o for accented characters, there are more robust ways to achieve that.)

Dave <barx>
Group Member


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

Attach Files:

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


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-a854.
    Corresponding source code