[webkit-dev] Ruby Text Enhancements
emader at apple.com
Wed Oct 6 10:34:49 PDT 2010
On Oct 5, 2010, at 6:25 PM, David Hyatt wrote:
> 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).
Yes, that did the trick! I haven't noticed any obvious problems with that line removed, but I haven't done much testing yet.
> (hyatt at apple.com)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev