bugGNU roff - Bugs: bug #61999, groff emits nonstandard forms of...


bug #61999: groff emits nonstandard forms of large Roman numerals

Submitter:  Dave <barx>
Submitted:  Mon 07 Feb 2022 12:17:43 AM UTC
Category:  Core Severity:  1 - Wish
Item Group:  Rendering/Cosmetics Status:  Postponed
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Tue 15 Mar 2022 10:11:40 AM UTC, comment #1: 

Hi, Dave,

Like you, I feel no urgency regarding this issue.

If I felt compelled to do something about it, which I don't, my choice would likely be to lower the "magnitude too big" threshold down to ±4,000, as you note.

If someone has a problem with that, we can invite them to submit an authoritatively documented prescription for the rendering of such impractically large numbers.

Setting status to "postponed", to await the arrival of such a person (or the revelation of problems with 'W' and 'Z' as currently used).

G. Branden Robinson <gbranden>
Group administrator
Mon 07 Feb 2022 12:17:43 AM UTC, original submission:  

This ticket documents a shortcoming in groff, but I'm not sure it's one that has any reasonable solution, and closing the ticket as Won't Fix might be the best resolution.

What's the sitch?

The question is how to represent 4,000 and higher as Roman numerals when the register format is "i" or "I".

Is that even a real problem?

Not really.  The reason this remains firmly theoretical, and there is probably no reason to expend resources on trying to resolve it, is that the sorts of registers that might be rendered as Roman numerals will never hold numbers that large.  Of values stored in registers, the ones that might need to be displayed as Roman numerals represent things like elements of outlines, section numbers, and page numbers of front matter, where numbers even in the hundreds are rare.  Conversely, a register holding a value of 12p, which on PostScript devices is stored as 12000, will never be displayed as a Roman numeral.

The register holding the largest number that will ever realistically need to be displayed in Roman is \n[year], and thus the problem is 1,978 years away.

OK, what's groff's issue with these numbers?

AT&T troff used, and thus groff now uses, W for 5,000 and Z for 10,000, enabling numbers up to 39,999 to be printed in Roman numeral form.

As bug #61998 points out, there is no single historical or modern standard representation for large numbers as Roman numerals; various systems have been employed.  However, troff's/groff's use of W and Z follows none of those systems; it is a troff peculiarity.

So it would be theoretically nice to have a switch telling groff to use representations for 5,000 and 10,000 that do align with some real-world practice.

You're so right! Let's add that switch!

Slow your roll, Sparky.  Not only is there no single standard for 5,000 and 10,000 -- meaning we have to arbitrarily choose one, or support multiple formats and let the user choose which she wants -- but most of the competing standards for such numbers require characters outside the regular alphabet.  Some of these characters do exist in Unicode, but are not part of most of groff's default fonts.  Other systems utilize overlines, which won't display well in terminals.

At the end of the day, the complexity of the problem, combined with the lack of real-world need for a solution, makes me think "do nothing" might be the best approach.  This bug report exists mostly to shine a light on the issue, and let groff developers weigh in if they disagree with my conclusions.

This is horrible! Is there any other solution?

An alternative to emitting nonsense Roman digits like W and Z might be to simply disallow these numbers from being displayed in Roman form at all.  groff already does this with 40,000 and above; this is documented in the Texinfo manual, and easily demonstrable:

$ cat roman
.nr n 40000
.af n i
.tm \nn
$ groff roman
troff:<standard input>:3: error: magnitude of '40000' too big for i or I format

It would be simple to adjust this threshold down to 4,000 instead.  This would (theoretically) create error conditions in previously working roff code, but that code only "worked" by emitting nonsense anyway; refusing to emit nonsense could be considered an improvement.  And, circling back to the top, it is vanishingly rare to need Roman-numeral representation of registers storing numbers higher than the current year.

Notably, CSTR #54 did not document the range of supported Roman numerals, so arguably that range was historically implementation-defined.  Groff documentation, on the other hand, has claimed to display Roman numerals up to 39,999 for over twenty years (specifically, commit 52a6d12a), so this change would overturn historical documented groff practice.  But I bet no one notices.

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.


    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-03-15 gbranden StatusNone Postponed
    2022-02-09 barx Summarygroff's emits nonstandard forms of large Roman numerals groff emits nonstandard forms of large Roman numerals

    Back to the top

    Powered by Savane 3.13-6ae7.
    Corresponding source code