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

[Greg Chicares]

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

In the code that follows, I think I understand almost everything;
but is the adjustment to column_margin_ exactly right?

    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
        // compensate for it by giving 1 extra pixel until we run out
        // of these "underflow" pixels.
        auto underflow = overflow_per_column * num_columns - overflow;

        for(auto& i : columns_)
            {
            if(i.is_hidden())
                {
                continue;
                }

            i.width_ -= overflow_per_column;

            if(underflow > 0)
                {
                i.width_++;
                underflow--;
                }
            }

        column_margin_ -= (overflow_per_column + 1) / 2;

        // We condensed the columns enough to make them fit, so no need
        // for the warning and we don't have any expanding columns, so
        // we're done.
        return;
        }

If overflow_per_column is 1, then column_margin_ -= 1
"           "          "  2,   "        "           1
"           "          "  3,   "        "           2
"           "          "  4,   "        "           2
The 'underflow' logic shrinks columns by the exact number of pixels
to use up all the available width. But the column_margin_ reduction
isn't exact due to truncation: when the margin is added (on both sides),
is the total of all (margin+column+margin) widths lower than the maximum,
so that this is just a small aesthetic issue, or is it too wide, so that
not everything fits?

Another question: before these adjustments are made, the total width
of all fixed columns is calculated:
    total_fixed += i.width_;
What determines that original width_ of each column? Is it calculated
from a mask like "999,999", which would have seven characters times the
number of PDF pixels per character? Does it include the margins on both
sides, or exclude it?