comment #4:

> tmac/a4.tmac is another place one paper size is redundantly
> hard-coded, but bug #62569 seeks to abolish that file.

This was done within days of the bug being filed.

The email message cited in comment #5 points out an additional device-specific location, src/devices/grolj4/lj4.cpp, that defines a small subset of the paper sizes listed in the original submission here.

tmac/a4.tmac is another place one paper size is redundantly hard-coded, but bug #62569 seeks to abolish that file.

comment #1:

> I'm quite happy to add code to gropdf to parse paper.tmac, if
> this considered to be the authoritive source.

I too don't have a clear idea what should be considered the authoritative source for paper sizes, but this proposal does at least bring the number of separate lists down from 3 to 2.

The algorithm paper.cpp uses to generate the A-D sizes is clever, but ultimately merely computes known and unchanging numbers, which could be more human-readably put in a list as is done in the other two places.  There's no particular need for these computations to be done at run time (though in C++ code I imagine they incur no measurable performance penalty).

The algorithm could be retooled as a little standalone utility that generates the canonical data set in a way all the other code could read, but even that I'm not convinced offers any advantage over just storing the data in a flat text file.

This was the subject of a recent email discussion (http://lists.gnu.org/r/groff/2022-04/msg00007.html), so may already be in progress.  But groff developers are looking at bigger issues at the moment, so I'm logging this in a bug report so it doesn't get forgotten.

The basic problems are:

1. paper sizes are defined in three different places in groff code;
2. some of these lists of sizes contain entries that are missing from the other lists.

To give some perspective, this does not result in any loss of functionality to the user: groff and its output drivers allow any arbitrary paper size to be specified.  Giving standard sizes recognized names is certainly a convenience to the user, but a particular name's absence does not prevent the user from specifying that paper size anyway using its dimensions.

Problem 2 is fairly simple to solve, as the existing code can be easily copy/pasted, with the new dimensions filled in, to create new size names.

But this still leaves the lists defined in three different places in the code.  A more maintainable solution, albeit one harder to implement, is to have one master location define all named paper sizes, and generate code for the three languages where this information is needed.

I realize this is not a trivial task, and whether the amount of work to develop and test such a framework is any less than maintaining the three lists as-is is a question I leave to the developers.  That is, problem 2 above should be addressed, and problem 1 maybe should be, but there may also be compelling reasons not to.  (I would suggest, though, that if the framework is left as-is, comments be added to each location pointing to the other two to alert future developers that any further updates need to be reflected in other places.)

The places in the groff source tree that define paper sizes are:

1. src/libs/libgroff/paper.cpp (some sizes generated algorithmically): C++
2. src/devices/gropdf/gropdf.pl: Perl (see the %ppsz hash)
3. tmac/papersize.tmac: roff

All three of these sets contain these sizes:

ledger
legal
letter
a0-a6
b0-b6
c0-c6

Sets (1) and (3) additionally include:

d0-d6
tabloid
statement
executive
com10
monarch
dl

Sets (1) and (2) additionally include a7.

Exclusive to set (1) are b7, c7, d7.

Exclusive to set (2) are a8-a10.