On Thu, May 05, 2005 at 03:09:36PM +0100, Angus Leeming wrote:
> Martin Vermeer wrote:
> 
> > Attached, please review
> > 
> > - Martin
> 
>       tabular.getCellInset(cell)->metrics(m, dim);
> +     if (!p_width.zero())
> +         dim.wid = m.base.textwidth;
> 
> Well, I can see what it does, but it seems a bit ugly. Surely, this should 
> be happening inside of InsetText? 

The problem is how to communicate to InsetText the fact that p_width is
nonzero. m.base.textwidth doesn't cut it; with p_width = 0 it equals
full text width, with p_width > 0 it is set equal to this. Nothing clear
to test for inside the cell.

> Also, if you look at the code:
 
> void InsetText::metrics(MetricsInfo & mi, Dimension & dim) const
> {
>         setViewCache(mi.base.bv);
>         mi.base.textwidth -= 2 * border_;
>         font_ = mi.base.font;
>         text_.font_ = mi.base.font;
>         text_.metrics(mi, dim);
>         dim.asc += border_;
>         dim.des += border_;
>         dim.wid += 2 * border_;
>         mi.base.textwidth += 2 * border_;
>         dim_ = dim;
> }
> 
> Note that your hack is invalidating the cached dim_. What are the 
> repurcussions of that?

Does it? I don't see that.

What it means AFAICS is that the textinset box remains smaller than the 
drawn table cell and tightly wrapped around the lyxtext. But this
"package" appears to be drawn and placed correctly. There is just
"wasteland" added inside the drawn cell borders, but...

> Looking deeper, it seems to me that this code is just hacked together.
> 
> Did you know that mi.base.textwidth is not changed at all by this 
> function? (I don't believe it's used at all by LyXText::metrics.)

It is used, if nonzero, to set maxwidth_, which seems to be used widely
in lyxtext. And no, it not is modified. So? 

What further happens is that dim.width is modified by the lyxtext's line
breaking algorithm. What comes out will be always smaller than
mi.base.textwidth == maxwidth_, or at most equal.
 
> Shouldn't we be using this 'max width' setting (that's what 
> mi.base.textwidth is, right?) in text_.metrics so that your hack isn't 
> needed at all?

The problem is not the 'max width' that mi.base.texwidth indeed
represents, but the circumstance that the actual width of the cell
(textinset) derives from the lyxtext inside it, i.e.. zero if empty and
then expanding. I understand that if p_width != 0 (fixed width) this is 
undesirable for the drawn table cell (a property of tabular). A 'min
width' problem so to say.
 
> Now I see why I try not to venture into these innards :)

I commiserate :-9

- Martin

Attachment: pgpBGcdFJVYpy.pgp
Description: PGP signature

Reply via email to