bugGNU roff - Bugs: bug #62344, [PATCH] Sync recognized names of...

 
 

bug #62344: [PATCH] Sync recognized names of paper sizes

Submitter:  Dave <barx>
Submitted:  Thu 21 Apr 2022 07:03:05 PM UTC
   
 
Category:  General Severity:  1 - Wish
Item Group:  Feature change Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 17 Aug 2023 07:21:34 AM UTC, comment #7: 

Comment #5 contains a link to a patch, so updating the summary to reflect this.

Dave <barx>
Group Member
Mon 07 Aug 2023 01:16:06 AM UTC, comment #6: 

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.

Dave <barx>
Group Member
Sun 06 Aug 2023 03:23:23 AM UTC, comment #5: 

A solution to this bug was proposed in http://lists.gnu.org/r/groff/2023-08/msg00027.html

Dave <barx>
Group Member
Fri 03 Jun 2022 06:18:25 PM UTC, comment #4: 

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

Dave <barx>
Group Member
Tue 26 Apr 2022 12:33:12 PM UTC, comment #3: 

Whoops, update the wrong ticket.  Reverting Status and "Assigned to".

G. Branden Robinson <gbranden>
Group administrator
Mon 25 Apr 2022 06:06:35 AM UTC, comment #2: 

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.

Dave <barx>
Group Member
Mon 25 Apr 2022 05:47:00 AM UTC, comment #1: 

Deri James wrote this in comment 4 of bug #62346; I'm copying it here as it seems more relevant to this bug:

"I'm pretty agnostic on the 'best' solution, I'm quite happy to add code to gropdf to parse paper.tmac, if this considered to be the authoritive source. Which has the advantage that a user can add their own paper sizes, there are several used in the print industry which we don't mention, and we are light on envelope sizes, i.e. an A4 envelope must be bigger than an A4 page, ’cos it would be a devil of a job to insert it!"

Dave <barx>
Group Member
Thu 21 Apr 2022 07:03:05 PM UTC, original submission:  

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.

Dave <barx>
Group Member

 

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

Attach Files:
   
   
Comment:
   

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 barx (proposed a solution: see comment #5)
  • -email is unavailable- added by gbranden (Updated the item)
  • -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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-08-17 barx SummarySync recognized names of paper sizes [PATCH] Sync recognized names of paper sizes
    2023-08-07 barx Carbon-Copy- Added -email is unavailable-
    2022-04-26 gbranden StatusIn Progress None
        Assigned togbranden None
    2022-04-26 gbranden StatusNone In Progress
        Assigned toNone gbranden

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code