kdelibs/khtml

Germain Garand germain at ebooksfrance.org
Tue May 25 07:48:27 BST 2004


Le Lundi 24 Mai 2004 17:51, Waldo Bastian a écrit :
> The problem seems to be due to RenderBox::position() that calls detach on
> the InlineBox, however it does not seem to make any attempt to clean up any
> of the pointers in the parent object still pointing to the detached
> InlineBox.
>
> See RenderBox::position() and
> RenderBlock::computeVerticalPositionsForLine()
>
> This was all committed in february by Germain.
>
> Germain, how is this supposed to work?
>

Hi Waldo,

I do recall being non-plussed by this RenderBox::position method. There were 
the usual paraphrastic comments of the "Nuke the box" kind but no real 
explanation - I should have watched closer.

The flow goes like this: we are iterating on the current BidiRuns (between two 
line breaks) in order to both construct InlineFlowBoxes out of InlineBoxes, 
and correctly position the underlying Render elements.
At computeVerticalPositionForLine time, InlineFlowBoxes are already 
constructed, but Replaced elements aren't positioned as per calculation yet 
(need to check that again, I don't see why it couldn't be done earlier and in 
a safer way since the updated m_overflowHeight isn't used).
Hence a last iteration on BidiRun elements to position the objects at the 
corresponding, calculated InlineBox coordinate.

So the detach can't be right. It would mean either that
- Replaced elements aren't part of the final InlineFlowBox (they are)
- We are not interested anymore in inner InlineBox elements of InlineFlowBoxes 
(we definetly are)


Greetings,
Germain






More information about the kfm-devel mailing list