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

[Vadim Zeitlin]

On Mon, 12 Mar 2018 15:22:50 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-03-10 12:09, Greg Chicares wrote:
GC> [... wx_table_generator::do_compute_column_widths_if_necessary() ...]
GC> > I'd express it in natural language as:
GC> > 
GC> > As originally laid out, the table is too wide. Calculate the number
GC> > of pixels by which it overflows--for the whole table:
GC> >   auto const overflow = total_fixed - total_width_;
GC> >     where total_width_ is the width of the page, e.g., 210mm for A4
GC> >     and total_fixed is width of all fixed-width columns, as
GC> >       originally laid out
GC> > ..and also for each column:
GC> >   // We need to round up in division here to be sure that all columns
GC> >   // fit into the available width.
GC> >   auto const overflow_per_column =
GC> >       (overflow + num_columns - 1)/num_columns;
GC> > Now determine whether reducing the margins will make the table fit.
GC> > If that works, then do it; else don't do it, and print a warning.
GC> 
GC> In the code that follows, I think I understand almost everything;
GC> but is the adjustment to column_margin_ exactly right?

 I think it's about as right as it can be when using integer coordinates.

GC>     if(overflow_per_column <= 2 * column_margin_)
GC>         {
GC>         // We are going to reduce the total width by more than
GC>         // necessary, in general, because of rounding up above, so
GC>         // compensate for it by giving 1 extra pixel until we run out
GC>         // of these "underflow" pixels.
GC>         auto underflow = overflow_per_column * num_columns - overflow;
GC> 
GC>         for(auto& i : columns_)
GC>             {
GC>             if(i.is_hidden())
GC>                 {
GC>                 continue;
GC>                 }
GC> 
GC>             i.width_ -= overflow_per_column;
GC> 
GC>             if(underflow > 0)
GC>                 {
GC>                 i.width_++;
GC>                 underflow--;
GC>                 }
GC>             }
GC> 
GC>         column_margin_ -= (overflow_per_column + 1) / 2;
GC> 
GC>         // We condensed the columns enough to make them fit, so no need
GC>         // for the warning and we don't have any expanding columns, so
GC>         // we're done.
GC>         return;
GC>         }
GC> 
GC> If overflow_per_column is 1, then column_margin_ -= 1
GC> "           "          "  2,   "        "           1
GC> "           "          "  3,   "        "           2
GC> "           "          "  4,   "        "           2
GC> The 'underflow' logic shrinks columns by the exact number of pixels
GC> to use up all the available width. But the column_margin_ reduction
GC> isn't exact due to truncation: when the margin is added (on both sides),
GC> is the total of all (margin+column+margin) widths lower than the maximum,
GC> so that this is just a small aesthetic issue, or is it too wide, so that
GC> not everything fits?

 This is an issue of aligning the column text, not of fitting, because the
margin is used when positioning the text inside the column width. And the
width is correct, so the worst that can happen here is that the text is
offset by 0.5 pixels -- but, of course, if we rounded it down, it would be
offset by 0.5 pixels in the other direction. So maybe we should write

        column_margin_ -= overflow_per_column / 2;

just because it's shorter and not necessarily worse (nor better).


GC> Another question: before these adjustments are made, the total width
GC> of all fixed columns is calculated:
GC>     total_fixed += i.width_;
GC> What determines that original width_ of each column? Is it calculated
GC> from a mask like "999,999",

 Yes. It's calculated from the mask, then increased to the header width, if
it's greater, and then increased by 2*column_margin_. All this happens in
wx_table_generator::add_column().

GC> Does it include the margins on both sides, or exclude it?

 The width includes margins on both sides.
VZ