kdelibs/khtml
Germain Garand
germain at ebooksfrance.com
Tue May 25 07:43:47 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