On Oct 5, 2010, at 7:33 PM, Eric Mader wrote: > > On Sep 24, 2010, at 8:02 PM, David Hyatt wrote: > >> This is a tough problem. It seems like you have to get involved in the line >> layout code e.g., findNextLineBreak in order to really do the right thing. >> findNextLineBreak uses an iterator that walks the objects, so it's easier to >> tell what text came before you and what text comes after you. You can also >> tell whether or not that text will even fit on the line and possibly do the >> margin hacking there. > > I just did a prototype that checks for a RenderRubyRun in the isReplaced() > code inside findNextLineBreak and calls a method on the RenderRubyRun that > takes the last and the next object and sets negative margins by calling > setMarginLeft() and setMarginRight(). I stepped through this code and it > computes the correct margins, but the margins don't seem to take - the ruby > doesn't overlap the surrounding text. > > Guessing that some other code is resetting the margins, I modified the code > to cache the computed margins in the RenderRubyRun object and return the > cached values through subclassed marginLeft() and marginRight() methods. With > this change, the ruby displays as I would expect.
It's probably RenderBlockLineLayout line 348 getting you in trouble (computeInlineDirectionPositionsForLine). computeLogicalWidth is called again, and that will recompute the left/right margins and blow away the changes you made to them. I have no idea why that call is there. It should not be necessary, but maybe there's something subtle I'm missing. You could try removing it, and see if that fixes the problem (it should). dave (hy...@apple.com)
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev