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

Reply via email to