Re: [lmi] do_compute_column_widths_if_necessary()

[Greg Chicares]

On 2018-04-21 22:50, Vadim Zeitlin wrote:
> 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?

What found difficult to understand was the fixed/variable dichotomy. Once
that's understood, is_variable_width() is as good as the complementary
has_fixed_width(). I do think I understand it now.

> 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.

That was part of my problem. How is a width "fixed" if it's adjustable?
I had to see that fixed-ness is a platonic form, and adjustment is just
a practical compromise in real life.

> 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.

That was another part of my problem. I really thought that "fixed"
columns were "expanded"...then, later and less incorrectly, that their
margins were "expanded", somewhere. IOW, I thought that upon entering
wx_table_generator::do_compute_column_widths() we had something like
  MMMMM-header-MMMMM
  MMMMM--data--MMMMM
with a five-em margin on both sides of a width-eight column, and then
that function removed some of the margins. That led me to wonder why
we'd add such wide margins in the first place, only to reduce them
later--and thus to imagine that a grand refactoring might combine all
such hypothetical code in order to set margins OAOO. (Fortunately, I
decided to try to understand everything better before setting off on
what would have been a fool's errand.)

But now I see that only a single em of bilateral margin is added in
add_column, so that removing a few points in do_compute_column_widths()
is merely a microscopic adjustment--a desperate and heroic effort to
make everything fit, which is wonderful if it works, but can work only
if the overflow is rather small (because presumptive margins of only
one em are close to minimal).

[...there might, in theory at least, be enough room to print all
fixed-width columns, but no room left over for any variable-width
column...]

> 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

We've all heard the proverb "the first woodpecker that came along would
destroy civilization". I take it as my personal mission to invalidate
Weinberg's law, so I need to define all fundamental terms, rigorously,
before I can begin to reason about them correctly.

> 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.

Yes, I'm coming to see that. What's problematic is not the existence of
such assumptions, but my imperfect understanding of them. Similarly, if
you felt you needed to understand exactly how lmi handles monthiversary
processing, I'm confident that you could achieve that goal, but the
easiest way would be to ask me a rather lengthy series of questions.

And some aspects of the design (of this PDF code, or similarly of the
monthiversary processing) reflect ill-advised business "requirements".
Thus, this is absurd on the face of it:

        bool is_centered()       const {return !is_variable_width_;}
        bool is_variable_width() const {return  is_variable_width_;}
        bool needs_clipping()    const {return  is_variable_width_;}

but the absurdity inheres in the business requirements. It's easy to
find such absurdities in the insurance logic of lmi, such as

  grep -A8 UnsplitSplit ihs_avstrtgy.cpp

and every time I need to deal with that silliness, I have to go back
and re-read that bit of inline documentation. My present goal is to
insert similar bits of commentary into 'wx_table_generator.?pp' so
that I can maintain it.