Re: [lmi] do_compute_column_widths_if_necessary()

[Vadim Zeitlin]

On Sat, 21 Apr 2018 22:12:33 +0000 Greg Chicares <address@hidden> wrote:

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

 I am not sure any more, I thought so, but seeing all the problems this
name causes, arguably it isn't. This was one reason I suggested
has_fixed_width() as the name of the accessor -- this should really be
completely unambiguous, shouldn't it?

GC> The reason I'm uncertain is that, if I understand correctly, the widths
GC> of all columns may be adjusted.

 It's true that now (this wasn't the case when this code was originally
written), all columns can be slightly adjusted if they don't fit in the
page otherwise. However logically some columns have fixed width, specified
by the string representing their typical contents, while the variable width
ones don't have any fixed width at all and just take all the rest of the
available space (which, of course, means that the fixed width columns will
_not_ be adjusted if a variable width column is used because there should
be enough space for this column left after allocating enough space to all
the fixed width columns, which wouldn't be the case if they didn't fit).

GC> E.g., on a PDF illustration (not a group quote), all
GC> columns have "fixed" width...but if there's extra horizontal space, don't
GC> we expand the columns to fit as follows?

 No.

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

 We don't even do this, it only goes in the other direction: we shrink the
default margins around them if the columns don't fit.

GC> So, disregarding margins, the widths of "fixed" columns truly are fixed,
GC> right?

 Yes.

GC> And then, logically, if they aren't "fixed", they are "variable",
GC> and the terminology really does make sense. A "variable" column like
GC> 
GC>   Participant
GC>   Thomas Hobbes
GC>   Antoine-Laurent de Lavoisier
GC> 
GC> can be expanded to a hundred-character width, or clipped to:
GC> 
GC>   Participant
GC>   Thomas Hobb
GC>   Antoine-Lau

 Yes, exactly.

GC> But now I have another question: if the fixed columns occupy all but five em
GC> of the available horizontal space, and margins are two em, then wouldn't the
GC> "Participant" column above become
GC> 
GC>   P
GC>   T
GC>   A
GC> 
GC> ? I think the answer is: yes, that's deliberate, as this column has no
GC> minimum width. I had wrongly assumed that its "Participant" header endowed
GC> it with a minimum width of eleven.

 The assumption here was that the variable width columns would be wide
enough to always fit their header contents. Even if it's not always true in
theory, I think it should be always the case in practice because I don't
think we can do anything reasonable if the fixed width columns take up so
much space that not enough of it is left even for the variable width column
header.

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

 It's unusual, rather than tedious, to go into such details, but I
understand why do you do it and I agree that it's useful to make all the
assumptions behind this class explicit. But having done this, I think it's
not really a problem to make them. This class is not supposed to be fully
general (would this even be possible, anyhow?), but just general enough to
allow using it for our two existing use cases. Also, while this does force
it to be more complicated than it could have been if it handled just one or
the other of them, I think it's worth adding some complexity to it in order
to allow reusing the code in both cases. I.e. even though there are some
clear differences, I believe that the commonalities overweight them and, in
spite of it being not as simple as it could have been, the class remains
simple enough to be relatively easy to extend if we need to support any
other kind of tables.

 Please let me know if there is anything else I can do to help you come to
understand this code better,
VZ