[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #62344] Sync recognized names of paper sizes

From: Dave
Subject: [bug #62344] Sync recognized names of paper sizes
Date: Thu, 21 Apr 2022 15:03:06 -0400 (EDT)


                 Summary: Sync recognized names of paper sizes
                 Project: GNU troff
            Submitted by: barx
            Submitted on: Thu 21 Apr 2022 02:03:05 PM CDT
                Category: General
                Severity: 1 - Wish
              Item Group: Feature change
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None



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:

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

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

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

0 src/libs/libgroff/paper.cpp
(some sizes generated algorithmically): C++
0 src/devices/gropdf/gropdf.pl
Perl (see the %ppsz hash)
0 tmac/papersize.tmac
<http://git.savannah.gnu.org/cgit/groff.git/tree/tmac/papersize.tmac>: roff

All three of these sets contain these sizes:


Sets (1) and (3) additionally include:


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

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

Exclusive to set (2) are a8-a10.


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]