On Sun, Sep 02, 2007 at 12:29:50AM +0200, Abdelrazak Younes wrote: > Alfredo Braunstein wrote: > > Abdelrazak Younes wrote: > >>> How can this work? You have to compute metrics on the restricted > >>> textwidth (less the button width) because that's how it's painted after. > >> That's because the InsetText dimension doesn't change, it stays lower > >> that 0.5 * workWidth, no matter if there's a button before. I assumed > >> blindly that the button width will fit in the remaining half screen but > >> I guess I am wrong and we need to make sure of that. In general this > >> should just work though because nobody will work with a work area which > >> width is less the size of a float button... I guess, I'll try it out... > > But what about deeply nested stuff, or stuff inside minipages etc. It seems > > difficult to come up with good heuristics to avoid that metrics call > > without using textwidth. > > I think that by testing he dimension of the button and if we forbid > openinlined if the button is too large wrt the screen, this is OK. > > > Could you remind me why of the comment "// This > > expression should not contain mi.base.texwidth" of line > > InsetCollapsable:212 ? > > No idea... is it my comment?
No, mine. It was added because, if this condition was not fulfilled, the inset would jump from top button to left button at a stage too late for the metrics calculation to still take into account, and we would get rendering 'turds'. - Martin
