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

[Greg Chicares]

On 2018-04-23 18:05, Greg Chicares wrote:
> On 2018-03-10 00:34, Greg Chicares wrote:
[...]
>> 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).

I think I've found the worst possible case.
 - File | Open | 'large-supp-rpt.ill'
 - on the "Reports" tab, select "SpecAmt" for all twelve columns
 - OK
 - Ctrl-I

[Don't make those selections with a mouse. Instead, do this:
  <Tab> <Home> S
twelve times.]

Only nine columns print: we're 192 pixels short, and only 168 can be
liberated by setting column margins to zero. Seeing that, we display
a warning, and skip the code that trims margins: we don't even try,
because we know see it won't make all columns fit. Then we print nine
columns, with comfortable (default) margins.

Is that the behavior we really want? Options [most require clipping]:
 (a) Refuse to generate a PDF: make the 'warning' an 'alarum' as we say.
 (b) Generate PDF, but don't even try trimming margins (above). Clip.
 (c) Generate PDF, trimming margins to zero. Clip.
 (d) Generate PDF, trimming margins to some nonzero minimum--e.g., one:
     we didn't make it fit, but we did the best we could. Clip.
 (e) Generate PDF, trimming margins to some readable minimum--e.g., three;
     if that would require clipping, then omit the last column and retry,
     repeating until enough columns have been omitted. No clipping.

My preference order, from worst to best, is
  c < b < d < a < e

(c): 900,000,000900,000,000900,000,000900,000,000900,000,000 is absurd.
(b): We had room for ten or eleven, so we gave you...nine? Huh?
(d): (I reserve the right to increase the minimum margin.)
(a): Perhaps too severe.
(e): Strictly better than (b) or (d) IMO.

Clipping always looks like an embarrassing mistake that a professional
wouldn't knowingly permit. [Clipping a 100-character personal name in a
group quote is an exception.]

With (e), having counted how many columns were omitted, we can phrase the
warning in terms of columns (which users understand) instead of "pixels"
or "points" (which they don't). (We could of course do that with (a) too.)

BTW, the XSL-FO code just manages to print this abomination legibly, but
this is so unlikely to arise in practice that I can't justify delaying
this very important wxPdfDoc-based modernization just because the old code
did this one implausible thing better.

Any user who needs that much information really should break it into two
supplemental reports: once we've made that easy by doing
  http://savannah.nongnu.org/support/?105589
    Allow multiple supplemental reports
  http://savannah.nongnu.org/support/?105590
    Save and retrieve supplemental reports
we can add a line to the messagebox suggesting that.

We certainly aren't going to add a "Fonts" dialog that enables end users
to print regulated presentations in six-point type that nobody can read.

BTW, having some letterpress experience, I naturally thought of using a
hair space...but when I added this line
  << "\n'HAIR SPACE' (U+200A) is " << dc_.GetTextExtent(u8"\u200A").x << " 
pixels wide."
to the messagebox to see what would happen, it said that would be
sixteen pixels wide.