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

[Greg Chicares]

On 2018-03-09 21:34, Vadim Zeitlin wrote:
> On Fri, 9 Mar 2018 18:07:18 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Easier way to reproduce:
> GC> 
> GC> wx_test --ash_nazg --data_path=/opt/lmi/data --pyx=only_new_pdf
> GC> 
> GC> pdf_census: started
> GC> pdf_census: ERROR (Assertion failure: A message box "Not enough space for 
> all fixed columns: 136 more pixels needed. [file 
> /opt/lmi/src/lmi/wx_table_generator.cpp, line 251] " was shown unexpectedly. 
> [file /opt/lmi/local/include/wx-3.1/wx/testing.h, line 427, in 
> ReportFailure()].)
[...]
>  I can confirm that I see this too with the MinGW-built binary. I still
> have no idea why don't I see it in the MSVC build and I'd like to find it
> out, but this is not the most pressing issue.

How strange. Reexamining an earlier message in that light:

On 2018-03-09 11:32, Vadim Zeitlin wrote:
| GC> and on the fifth page (4 of 7) the numeric columns exceed the available
| GC> page width.
|
|  And I don't see this neither. I do see the overlap between "Investment
| Income" and "Account Value" columns however

I wonder whether we're looking at the same thing. For me, the indicated page
has a table that's missing two entire columns; and the PDF doesn't contain
the word "Investment" anywhere on any page.

>  The real problem is that there is just no magic way of making the message
> above disappear, other than by reducing the columns widths (and, maybe,
> margins, to make them even narrower than they used to be before). Note that
> the number in the error message is misleading because it doesn't take into
> account the possible reduction in the margins sizes which is ~100px for the
> widest tables, so the overflow is not that big. But we still need to
> sacrifice something here, be it the width of some columns (if any of them
> don't need to be as wide as they're now), left and right page margins or
> the inter-column margins (to an even greater extent than we already do).

I tried to copy and paste from the PDF, but that never works, so I'll type
a part of this table by hand. (It would be really handy right now if we had
an option to write flat-text files with content identical to the PDFs.)

0000000001111111111222222222233333333334444444444555555555566666666667
1234567890123456789012345678901234567890123456789012345678901234567890
Policy     Premium     Account   Cash Surr       Death
  Year      Outlay       Value       Value     Benefit
     5 999,999,999 999,999,999 999,999,999 999,999,999
      000000000111111111122222222223333333333444444444
      123456789012345678901234567890123456789012345678

The AutoScale() technique ensures that the largest number in this table is
less than one billion (to avoid British-English ambiguity, one gigadollar).
[Already I see a latent error--aren't these values formatted in a way that
rounds them, so that $999,999,999.99 would become "1,000,000,000"? I'll
have to work on that.]

Anyway, assuming AutoScale() provides not a 99.99999995% likelihood but a
reliable 100% guarantee, each number has a width of twelve en (or perhaps
a little less if this font makes commas narrower than digits).

The last three columns repeat three times, so the table's total width is
   6 en for Policy Year
  12 en for Premium Outlay
  36 en for the {AV,CSV,DB} triplet on the guaranteed basis
  36 en for the same on the midpoint basis
  36 en for the same on the current basis
 126 en total, excluding margins

Do we have 126 en available? If so, then we just lay out this table with
one space between columns, and it has to fit.

If we don't have that much space with the current font, then we must
reconsider either the scaling or the font, or look at the problem in a
fundamentally different way.

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; I can ask whether that would be acceptable. I
don't think a maximum of 9,999,999 would be high enough, because these
values very often exceed $10M by age 70.

B. Font

B.0. First of all, what font size are we using? How can I tell?
How can I ascertain a built-in PDF font's metrics, e.g., x-height?

B.1. Use a narrower font. I believe we already found that digits are
narrower with Times than with Helvetica. Are there any other feasible
options within the built-in fonts guaranteed to be valid in any PDF?
If this turns out to be the best answer, then we'll have to consider
whether to use a narrower font only for this table, or for all tables.

B.2. Embed a custom font with narrower digits. This seems to be a
heavyweight solution that we'd consider only if no other option seems
workable. Of course, it would need to be GPL-compatible.

B.3. Make the commas narrower. I just looked at a magnified PDF, and
it looks like the commas are about half an en. We have twenty commas
per line in the table above, taking ten en. If we could find a narrower
comma, we might save a total of five en per line. This doesn't seem
promising.

B.4. Omit the commas. I don't think this will be accepted.

B.5. Reduce the font size. There may be a common practice that we must
follow; if there is, it's probably expressed as the font's "point size",
e.g., "12 point", because it was decided in the letterpress age. We can
make the argument that, e.g., 11pt Helvetica digits look as big as
12pt Roman; I can't be sure whether that will be accepted.

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. But, if it is,
then we could propose stacking the triplets of columns vertically.
E.g., instead of a single row consisting of the five columns I typed
in by hand above, plus the midpoint and current triplets I didn't
(for a total of eleven columns), we'd have three tables of five
columns each. I don't know whether this will be accepted; I can ask.

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).

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.