[bug #61999] groff's emits nonstandard forms of large Roman numerals

[Dave]

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

                 Summary: groff's emits nonstandard forms of large Roman
numerals
                 Project: GNU troff
            Submitted by: barx
            Submitted on: Sun 06 Feb 2022 06:17:43 PM CST
                Category: Core
                Severity: 1 - Wish
              Item Group: Rendering/Cosmetics
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

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
40000


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
<http://git.savannah.gnu.org/cgit/groff.git/commit/?id=52a6d12a>), so this
change would overturn historical documented groff practice.  But I bet no one
notices.




    _______________________________________________________

Reply to this item at:

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

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