Re: [lmi] do_compute_column_widths_if_necessary()

[Greg Chicares]

On 2018-04-21 13:08, Vadim Zeitlin wrote:
> On Sat, 21 Apr 2018 00:57:40 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> AIUI, "variable-width" columns have width zero when constructed,
> GC> and 'is_variable_width_' captures that status.
> 
>  Yes.

Is "variable width" the best description of this property? The reason I'm
uncertain is that, if I understand correctly, the widths of all columns
may be adjusted. E.g., on a PDF illustration (not a group quote), all
columns have "fixed" width...but if there's extra horizontal space, don't
we expand the columns to fit as follows?

[The '|' characters are just markup, to be understood as having 0 width.]

  | fixed 10 |    fixed 16    | fixed 10 |
  |0123456789|0123456789ABCDEF|0123456789|

Total width is 36, so, to fit in printable width of 48, expand columns...

  |   fixed 10   |      fixed 16      |   fixed 10   |
  |  0123456789  |  0123456789ABCDEF  |  0123456789  |
   00000000011111 11111222222222233333 33333444444444
   12345678901234 56789012345678901234 56789012345678

But wait--having drawn that, I think I understand: we don't actually
widen the columns; instead, we widen the margins 'M' around them:

  |M| fixed 10 |M|M|    fixed 16    |M|M| fixed 10 |M|
  |M|0123456789|M|M|0123456789ABCDEF|M|M|0123456789|M|
   00000000011111 11111222222222233333 33333444444444
   12345678901234 56789012345678901234 56789012345678

So, disregarding margins, the widths of "fixed" columns truly are fixed,
right? And then, logically, if they aren't "fixed", they are "variable",
and the terminology really does make sense. A "variable" column like

  Participant
  Thomas Hobbes
  Antoine-Laurent de Lavoisier

can be expanded to a hundred-character width, or clipped to:

  Participant
  Thomas Hobb
  Antoine-Lau

> GC> However, it seems that width_ is increased to the width of the column
> GC> header, before the snippet above is reached,
> 
>  I don't think this is the case, where do you see this happen?

Ah, now I see what I was missing, in add_column():

        // Also increase the column width to be sufficiently wide to fit
        // this header line if it has fixed width.
        if(0 != width)
            {
            increase_to_if_smaller(width, dc_.GetMultiLineTextExtent(header).x);

> GC> where I conjecture that (0 == i.width_) may never be true.
> 
>  If it were true, the group quote display would be broken as the "Name"
> column wouldn't be shown as wide as it should be. The last time I tested
> this this wasn't the case.

Okay, thanks.

But now I have another question: if the fixed columns occupy all but five em
of the available horizontal space, and margins are two em, then wouldn't the
"Participant" column above become

  P
  T
  A

? I think the answer is: yes, that's deliberate, as this column has no
minimum width. I had wrongly assumed that its "Participant" header endowed
it with a minimum width of eleven.

I realize that no such thing happens to occur in practice, but that's only
because of how wx_table_generator is used. But I'm trying to understand
this class as an independent abstraction, and I can only achieve that by
making sure I grasp all these details first. Sorry, this must be tedious
for you.