[webkit-dev] Two Pass Layout?

[Alex Milowski]

On Thu, Sep 17, 2009 at 11:36 PM, Roland Steiner
<rolandsteiner at google.com> wrote:
> Hi Alex,
> I'm in the process of doing ruby layout, currently under review (reviewers:
> *hint, hint*), where I had several of the same issues, albeit not quite as
> severe as with MathML (in effect, one could see ruby as nothing than a
> series of <mover>/<munder> operations).

Is there a patch I can take a peek at?

> I'm not sure how far my experiences
> can help you, but let me add some comments:
> On Fri, Sep 18, 2009 at 4:45 AM, Alex Milowski <alex at milowski.org> wrote:
>>
>> I'd like to re-oriented the code I have to include an RenderMathOperator
>> class
>> that can stretch operators that stretchable and do something else for ones
>> that aren't (e.g. curly brackets can be stretched but angle brackets can
>> only
>> be resized by font size to a certain maximum before they look strange).
>
> Note that for "correct" rendering, even stacking braces need to change font
> sizes from time to time, so that the overall impression of weight stays
> proportionate. That is, even if you have stacking braces, their width may
> change.

Well, to some extent the way glyph stacking works is you pick a certain
font size in pixels.  You then stack the glyphs by determining how many
of that size you need to fill a certain pixel height.  Then zooming/etc. all
seem to work well afterwards.  Oddly, for stretchy operators, the current
font size isn't much of a consideration because you are building a large
glyph out of smaller glyphs.


> Also note that the DOM may be manipulated afterwards - nodes added or
> removed, causing recalculations or even add/remove line breaks (so you need
> to be careful when caching values).
> As for calulations, adding special anonymous boxes to group stuff into
> smaller chunks might help (not sure there is actually a need for such things
> in MathML). OTOH, such boxes also adds complexity when it comes to DOM
> manipulation.

Very true.  I haven't looked into how the rendering interacts with DOM changes.
I assume, as some point, layout calls will be needed again.  In this case,
I'd need to know when the siblings change size.  Is there some event that
gets propagated for that kind of thing that turns into a sequence of method
calls for notification?


>
>>
>> The consequence of this, as I've noted before, is that I somehow need
>> to "invalidate" the line boxes for the containing inline-block for the
>> mrow/mfenced.  I've tried this a number of ways but it seems that things
>> go wrong when the mrow/mfenced contains certain kind of replaced
>> content (e.g. inline-table).
>
> Not sure I understand the requirements correctly, but can't you just nuke
> the line boxes with deleteLineBoxTree() and have them rebuilt?

I'll have to try that and see what happens.  The part I don't get rendering
is how nested replaced objects seem to get treated different.  That is,
if I call layout() twice with online inline content (and so a sequence of
regular line boxes), bad things happen.  If I call layout() twice with
a nested mfenced (an inline-block and so replaced content), the right
thing happens.  If I call layout() twice with a nested mtable, bad things
happen.

That all indicates to me that I need to either:

   * prepare for layout to be called again be somehow invalidating what
     was done before
   * use methods that are "below" layout() and not call layout twice.

I'm trying to keep what RenderBlock does to layout inline children because
it does work properly in most cases.  It is only in this two-pass case
where I need to do something special.  In fact, even in that two-pass case,
if I somehow magically knew the right size for things like the stretchy
operators a priori, it would work perfectly.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics