On Thu, 2006-06-22 at 12:23 +0200, Jean-Marc Lasgouttes wrote: > >>>>> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> I suppose the speed-up patch exposed this bug, i.e., that a > Martin> tabular cell with a non-fixed width does not transmit a > Martin> sensible mi.base.textwidth to any textinsets it contains. Now > Martin> that we use this (or the derived maxwidth_) to decide how much > Martin> space to give to a Wide inset, this becomes visible. > > And do you think it would be too difficult to fix the real cause?
My patch does that... imperfectly. The value is now sensible, but often a bit generous. > Martin> Attached the tabular background patch for 1.4 (still not > Martin> applied) > > This part is OK. > > Martin> with code added to fix this problem (first chunk). The code is > Martin> ugly (deciding how much space the stuff in the cell needs, and > Martin> then giving a little more) but seems to do the trick. > > There is still something wrong: in an empty tabular, if I insert a > note inset, it the cell will be larger than what the inset needs. if I > begin to type inside the inset, the extra space remains until some > point where it brutally disappears. > > What seems to happen actually, is that the inset is drawn with the > button above, but its width is computed as if the button was on the > left (as it should). The point when the extra space disappears > corresponds to the situation where the button should indeed be on top. Yes... I see that too. What actually happens is (as I understand) 1) the width of the cell is computed initially based on the assumption that the whole screen width is available -> the note inset will be "inlined". 2) This computed value is taken, transmitted to the tabular, and used (incremented by 1) to set the cell (i.e., textinset) metrics. 3) The note inset (if "Wide") takes this value as the width it has available to live in, and decides on this basis that it will be non-inlined (button above). See insetcollapsable to understand this behaviour. I have been playing around with this code in order to make the extra space disappear, but with little success. The opposite error where the cell space is too small to accomodate the note is worse -- and I saw a lot of that in my experimentation :-( An easier fix might be to have another look at the openinlined_ behaviour in insetcollapsable. Shall I commit this patch to 1.4 (and 1.5) as it creates sane behaviour with only a cosmetic wart? - Martin
signature.asc
Description: This is a digitally signed message part
