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

[Vadim Zeitlin]

On Sat, 10 Mar 2018 00:34:27 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-03-09 21:34, Vadim Zeitlin wrote:

 First of all, let me evacuate this:

GC> How strange. Reexamining an earlier message in that light:
GC> 
GC> On 2018-03-09 11:32, Vadim Zeitlin wrote:
GC> | GC> and on the fifth page (4 of 7) the numeric columns exceed the 
available
GC> | GC> page width.
GC> |
GC> |  And I don't see this neither. I do see the overlap between "Investment
GC> | Income" and "Account Value" columns however
GC> 
GC> I wonder whether we're looking at the same thing.

 No, we don't, because I stupidly forgot that I had changed the ledger type
to "individual private placement" to test something else before, and forgot
to change it back to "regular". After having done so, I can see the problem
perfectly well with MSVC too, which is reassuring -- just sorry to have
wasted your and Kimberly's time!

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

 Strange, it doesn't work perfectly (i.e. some layout is lost), but it does
work for me (using Sumatra PDF viewer).

GC> 0000000001111111111222222222233333333334444444444555555555566666666667
GC> 1234567890123456789012345678901234567890123456789012345678901234567890
GC> Policy     Premium     Account   Cash Surr       Death
GC>   Year      Outlay       Value       Value     Benefit
GC>      5 999,999,999 999,999,999 999,999,999 999,999,999
GC>       000000000111111111122222222223333333333444444444
GC>       123456789012345678901234567890123456789012345678
[...]
GC> Anyway, assuming AutoScale() provides not a 99.99999995% likelihood but a
GC> reliable 100% guarantee, each number has a width of twelve en (or perhaps
GC> a little less if this font makes commas narrower than digits).

 At least in the MSVC build (but I really don't see why would it be
different with MinGW), with of "9" is 5 (in units of PDF pixels, which
are the same as points in our code), so the width of the first column is 15
and the width of each of the gigadollar-valued fields is 50, giving us
15 + 10*50 = 515 for the absolutely minimal required width, which is less
than the available width of 576 (obtained by subtracting 36, corresponding
to the current margin of 18, from the PDF page width of 612).

 However this doesn't take a couple of things into account: first, the
columns must be wide enough to show their headers. This is irrelevant for
the gigadollar columns, but does increase the width of the "Policy Year"
column, for example. Second, there are margins and gaps between groups of
columns (indicated by "-" in the column definition arrays).

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

 It does fit if we allow having no column margin at all (which we more or
less have to do as there is just 1 pixel of it left for this table anyhow):

---------------------------------- >8 --------------------------------------
diff --git a/wx_table_generator.cpp b/wx_table_generator.cpp
index 604351e3e..5b96d9059 100644
--- a/wx_table_generator.cpp
+++ b/wx_table_generator.cpp
@@ -211,7 +211,7 @@ void 
wx_table_generator::do_compute_column_widths_if_necessary()
             // fit into the available width.
             auto const overflow_per_column =
                 (overflow + num_columns - 1)/num_columns;
-            if(overflow_per_column <= column_margin_)
+            if(overflow_per_column <= 2*column_margin_)
                 {
                 // We are going to reduce the total width by more than
                 // necessary, in general, because of rounding up above, so
---------------------------------- >8 --------------------------------------

 If this is acceptable, and if we're not going to have any tables wider
than this (which I'm not all too sure about, e.g. are the widths for the
NASD supplemental table, which has even more columns, correct?), I think we
should just do this -- and you don't really need to read anything below.


GC> A. Scaling
GC> 
GC> A.1. Scale this one table independently of other tables. Certainly
GC> difficult, and probably confusing.
GC> 
GC> A.2. Scale everything differently: e.g., instead of a 999,999,999, make
GC> the maximum 99,999,999; I can ask whether that would be acceptable. I
GC> don't think a maximum of 9,999,999 would be high enough, because these
GC> values very often exceed $10M by age 70.

 I think both of these solutions suffer from the tail-wags-dog-itis and
don't really make sense.

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

 I'm not sure about this, but it's simple enough to insert a call to
wxDC::GetTextExtent() into the PDF code (if the existing ones are
insufficient) and examine the result under debugger or just add a printf()
or equivalent to see it on the console.

GC> B.1. Use a narrower font. I believe we already found that digits are
GC> narrower with Times than with Helvetica. Are there any other feasible
GC> options within the built-in fonts guaranteed to be valid in any PDF?

 No, Times and Helvetica are the only built-in fonts.

GC> If this turns out to be the best answer, then we'll have to consider
GC> whether to use a narrower font only for this table, or for all tables.

 I think it would be a very bad idea to use different fonts for different
tables.

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

 I'm really not an expert in the questions of font licencing (even less so
than in the questions of software licencing, as incredible as it seems), so
I have no idea whether we can find a narrow Helvetica variant under GPL. I
do know that font embedding is supported by wxPdfDocument (although I
didn't test it yet).

GC> B.3. Make the commas narrower. I just looked at a magnified PDF, and
GC> it looks like the commas are about half an en. We have twenty commas
GC> per line in the table above, taking ten en. If we could find a narrower
GC> comma, we might save a total of five en per line. This doesn't seem
GC> promising.
GC> 
GC> B.4. Omit the commas. I don't think this will be accepted.
GC> 
GC> B.5. Reduce the font size. There may be a common practice that we must
GC> follow; if there is, it's probably expressed as the font's "point size",
GC> e.g., "12 point", because it was decided in the letterpress age. We can
GC> make the argument that, e.g., 11pt Helvetica digits look as big as
GC> 12pt Roman; I can't be sure whether that will be accepted.

 Readability would definitely suffer with all of those...


GC> C. Fundamental redesign
GC> 
GC> C.1. Perhaps this table is the widest we have--wider than any other,
GC> for any ledger type, and wider than any user-designed supplemental
GC> report can be. I don't know whether that's the case.

 Me neither, but I think we should have a test case with what can be
reasonable considered to be the widest possible table, so it would be
really nice to establish this.

GC> C.2. Make column widths variable instead of fixed
GC> 
GC> This might perhaps produce a more attractive layout, in return for
GC> more work (yet that benefit might not exceed the cost).

 This probably won't be very difficult, at least if we keep the same column
widths across all pages for the tables spanning more than one of them. But
I don't think it will really help neither...

GC> But I don't
GC> like it as a strategy for avoiding page-width overflow: I imagine
GC> we could create scenarios that need nine digits in each column.

 ... because of this.


 The simplest idea by far remains to revert to using Times as we can be
sure that all tables that fit before will continue to fit. But perhaps
we're very lucky and using Helvetica just about works too. If it doesn't,
then I think using a narrower, yet still [more] readable [than Times] font
would be the best solution.

 Regards,
VZ