Re: [lmi] Group-quote PDF: whitespace changes, and enhancement

[Greg Chicares]

On 2018-03-10 00:34, Greg Chicares wrote:
>
[...an example where columns didn't all fit in the printable page width...]
> 
> A. Scaling
> 
> A.1. Scale this one table independently of other tables. Certainly
> difficult, and probably confusing.
> 
> A.2. Scale everything differently: e.g., instead of a 999,999,999, make
> the maximum 99,999,999
> 
> B. Font
> B.1. Use a narrower font.
> B.2. Embed a custom font with narrower digits.
> B.3. Make the commas narrower.
> B.4. Omit the commas. I don't think this will be accepted.
> B.5. Reduce the font size.
> 
> C. Fundamental redesign
> 
> C.1. Perhaps this table is the widest we have--wider than any other,
> for any ledger type, and wider than any user-designed supplemental
> report can be. I don't know whether that's the case.

It wasn't. We constructed a user-designed supplemental report that's
wider ('large-supp-rpt.ill', shared off the list).

> However, I think this is a dead end. Supplemental reports currently
> allow twelve columns (I just checked). A proposal to reduce that
> number will probably meet resistance. Twelve columns times 12 en is
> 144 en; that seems to be the actual maximum that must be accommodated
> (plus at least a few en for margins).

Left and right page margins are both a quarter of an inch, so the
printable width on 8-1/2 X 11 paper is eight inches, which is
  576 = 8 * 72
pixels.

"M" is 7 pixels wide.
"N" is 6 pixels wide.
"9" is 5 pixels wide; so is "1".
',' is 3 pixels wide.

A "999,999,999" column is thus 15+3+15+3+15 = 51 pixels.

Let's suppose we need at least five pixels between columns. Then
  twelve columns need 51*12 + 5*11 = 667 pixels,
  eleven columns need 51*11 + 5*10 = 611 pixels, and
  ten    columns need 51*10 + 5* 9 = 555 pixels.
We can always fit ten. We can't fit eleven or twelve if they're
all of maximal "999,999,999" width.

But they aren't all that wide: e.g., ages can't exceed 999. It's
uncommon to design a supplemental report with eleven or twelve
columns. The one discussed in the preceding email has eleven
columns, but the first two are year and age, which are narrow;
that report fits because hard-coded supplemental reports have
hard-coded widths, and year and age were made narrower there.

For user-designed supplemental reports, however, we've been
assuming "999,999,999" for all columns. I've just pushed
commit d3552b46d58, which demonstrates a way to make selected
columns narrower (it doesn't do that for all columns, but I
wanted to share a demonstration now).

> C.2. Make column widths variable instead of fixed
> 
> This might perhaps produce a more attractive layout, in return for
> more work (yet that benefit might not exceed the cost). But I don't
> like it as a strategy for avoiding page-width overflow: I imagine
> we could create scenarios that need nine digits in each column.

On second thought, it's difficult to create such a scenario:
age and year are almost always wanted, and when they're used,
more space is available. Though I haven't yet tried to create
a worst-possible-case input file, we can safely say that it's
unlikely to arise often in practice.

Dynamically determining the maximum width actually required
may be worth the effort. We already format each number, so it
is possible to take note of the widest element in each column.
We already measure header widths, and commit d3552b46d58 shows
how some headers might be made more narrow.

I think I'll finish the work begin in commit d3552b46d58 by
providing an appropriate mask like "999,999" for every column,
and then perhaps move on to something else. Fully dynamic
width adjustment will produce a more attractive presentation,
and we might want to do that eventually, but I'm reluctant to
put that on the critical path because life with XSL-FO is so
distressful that it's better to replace it with something
good now, and then made the good better, later.