mfenced - more MathML questions
I've been doing some comprehensive testing and find that my technique for handling fencing isn't working properly when use in nest constructs or other situations. Specifically, the two major problems are: * the fences do not scale well for large objects * nested fencing does not seem to be handled properly The first problem is probably something where I'll need to special cast certain common fencing constructors (e.g. square or curly brackets) and draw them directly. For example, a matrix bracketed by square brackets will probably only look proper when I draw the brackes directly. The problem of nested fences is much more tricky. I thought I had a handle on this with the only odd thing being the need to adjust the fence size after a layout pass. You can see this code in the patch [1] and specifically by looking and RenderFenced.cpp in [2]. I've been able to make it behave a bit better by calling setHeight() with the fence height online #205. It still has trouble laying out the the open and close fences and often overlaps the line boxes. The real problem seems to relate to nested mfenced constructs. A single mfenced works but an construct like: { < x > } does not work properly when the 'x' construct has an extended vertical height (e.g. a rational function or other large fraction). Then the nested mfenced seems to get mixed up. Again, it is like it is trying to constrain the fencing into a certain box width or height, the line boxes do not fit, and then overlap happens. Is it possible that just setting the height doesn't help because it is a writing direction layout/width problem? [1] https://bugs.webkit.org/show_bug.cgi?id=28982 [2] https://bugs.webkit.org/attachment.cgi?id=39223&action=prettypatch -- --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
On Tue, Sep 8, 2009 at 4:30 PM, Alex Milowski<alex@milowski.org> wrote:
The problem of nested fences is much more tricky. I thought I had a handle on this with the only odd thing being the need to adjust the fence size after a layout pass. You can see this code in the patch [1] and specifically by looking and RenderFenced.cpp in [2].
I've been able to make it behave a bit better by calling setHeight() with the fence height online #205. It still has trouble laying out the the open and close fences and often overlaps the line boxes.
I've been able to make some progress on nested mfenced. The problem is a bit more general in that: * any nested complicated construct (e.g. a mtable) has the same issue. * inline mathml embedded in a sentence with mfenced sometimes fails. I was able to fix the specific situation of mfenced nested in an mfenced by another call to RenderBlock::layout() directly within my layout() method instance. Unfortunately, doing that for an mtable nested in an mfenced (e.g. a matrix) makes things worse. I believe the core issue is that the whole layout is invalidated by the resizing of the fencing. I need to do this after the height of the contents is determined. Is there a way to determine the height of a contained RenderObject instance without going through the whole layout? If I could do that, I could adjust the height of the fences and then call layout. Also, I've been wrapping content in anonymous rendering objects to aid in my adjustments and layout. Do you think it would be to my advantage to wrap the contents that is fenced with an anonymous inline block? Otherwise, I need a way to say: "This whole subtree is now invalid as I resized content before and after it". I am very close. I have been able to load and render most of my MA thesis. If I fix the fencing, it will work for that document! -- --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
It's hard for me to understand what this problem is without more information. Are these objects inlines or blocks or what? dave On Sep 8, 2009, at 6:30 PM, Alex Milowski wrote:
I've been doing some comprehensive testing and find that my technique for handling fencing isn't working properly when use in nest constructs or other situations.
Specifically, the two major problems are:
* the fences do not scale well for large objects * nested fencing does not seem to be handled properly
The first problem is probably something where I'll need to special cast certain common fencing constructors (e.g. square or curly brackets) and draw them directly. For example, a matrix bracketed by square brackets will probably only look proper when I draw the brackes directly.
The problem of nested fences is much more tricky. I thought I had a handle on this with the only odd thing being the need to adjust the fence size after a layout pass. You can see this code in the patch [1] and specifically by looking and RenderFenced.cpp in [2].
I've been able to make it behave a bit better by calling setHeight() with the fence height online #205. It still has trouble laying out the the open and close fences and often overlaps the line boxes.
The real problem seems to relate to nested mfenced constructs. A single mfenced works but an construct like:
{ < x > }
does not work properly when the 'x' construct has an extended vertical height (e.g. a rational function or other large fraction). Then the nested mfenced seems to get mixed up. Again, it is like it is trying to constrain the fencing into a certain box width or height, the line boxes do not fit, and then overlap happens.
Is it possible that just setting the height doesn't help because it is a writing direction layout/width problem?
[1] https://bugs.webkit.org/show_bug.cgi?id=28982 [2] https://bugs.webkit.org/attachment.cgi?id=39223&action=prettypatch
-- --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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Wed, Sep 9, 2009 at 9:08 AM, David Hyatt<hyatt@apple.com> wrote:
It's hard for me to understand what this problem is without more information. Are these objects inlines or blocks or what?
They are a sequence of inline (e.g. mi or mn elements) or inline-blocks (i.e. more complicated elements like mfrac or other mfenced) contained in an inline-block for the mfenced. The fences (e.g. curly braces) are added by the rendered as anonymous inlines (RenderInline instances) before and after the sequence of added children. The contain a single RenderText instance containing the fence character. I've switched these over to inline-blocks but that hasn't really helped. -- --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
So fencing should extend from the line top to the line bottom it sounds like without affecting the overall height of the line? Have you tried placing them with a y position of the root line box's line top and a height of line bottom - line top? dave On Sep 9, 2009, at 12:39 PM, Alex Milowski wrote:
On Wed, Sep 9, 2009 at 9:08 AM, David Hyatt<hyatt@apple.com> wrote:
It's hard for me to understand what this problem is without more information. Are these objects inlines or blocks or what?
They are a sequence of inline (e.g. mi or mn elements) or inline- blocks (i.e. more complicated elements like mfrac or other mfenced) contained in an inline-block for the mfenced.
The fences (e.g. curly braces) are added by the rendered as anonymous inlines (RenderInline instances) before and after the sequence of added children. The contain a single RenderText instance containing the fence character. I've switched these over to inline-blocks but that hasn't really helped.
-- --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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
I guess that might make the fence too tall if something outside of it is taller than what's inside. You may have to just drill into your children line boxes in order to compute your top and your bottom position. We don't really have the concept of caching "line top" and "line bottom" except on the root line box.... dave On Sep 9, 2009, at 12:39 PM, Alex Milowski wrote:
On Wed, Sep 9, 2009 at 9:08 AM, David Hyatt<hyatt@apple.com> wrote:
It's hard for me to understand what this problem is without more information. Are these objects inlines or blocks or what?
They are a sequence of inline (e.g. mi or mn elements) or inline- blocks (i.e. more complicated elements like mfrac or other mfenced) contained in an inline-block for the mfenced.
The fences (e.g. curly braces) are added by the rendered as anonymous inlines (RenderInline instances) before and after the sequence of added children. The contain a single RenderText instance containing the fence character. I've switched these over to inline-blocks but that hasn't really helped.
-- --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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Wed, Sep 9, 2009 at 2:17 PM, David Hyatt<hyatt@apple.com> wrote:
I guess that might make the fence too tall if something outside of it is taller than what's inside. You may have to just drill into your children line boxes in order to compute your top and your bottom position. We don't really have the concept of caching "line top" and "line bottom" except on the root line box....
I think what throws this off is the width of the fence changes as I scale the font size. That causes the whole layout to need to "shift". In some instances I can get that to work but I can't seem to get it to consistently work. When I move to glyph stacking, the width will be fixed and I'll be able to determine that when I create the fences (pre-layout). Unfortunately, there are plenty of places where I'll need to change the width of something and that will cause the same problem. For example: <munder> <mo>→</mo> <!-- right arrow --> <mtext>maps to</mtext> </munder> The arrow is considered "stretchy" and should be stretched slightly longer then the rendered width of the text in 'mtext'. Again, you'd lay this out vertically and then check the maximum width. Afterwards, you'd stretch the operator (right arrow) to the desired width by stacking glyphs left-to-right. That will cause the next item in the flow to need to be repositioned and that is the same problem I'm having. I can do this in javascript manually and so there must be some way to say: "It is now invalid from here forward and so re-layout the following tree" ? -- --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
participants (2)
-
Alex Milowski
-
David Hyatt