[webkit-dev] mathml support in webkit / khtml

[Andy Somogyi]

Hello all

I'm working on a new mathml component that will be part of kdom / khtml2.
I have just commited my first set of imports to the new kmathml component.
Currently, most of the mathml dom objects are stubbed out, but there is 
nothing in the
way of rendering yet.

I'm looking for some input as to what is the best way to intgrate mathml 
support
into kthml.

In my previous mathml application, a windows mathml display and editing  
control
http://numerator.sourceforge.net
I use a fairly complex logic to layout and display mathml, so
I wanted to discuss the layout logic I use, and get some discussion going on 
whether or not
this is the best layout logic to use in a kdom component, how well would 
this approach integrate
with khtml and so forth.

So, here is a quick overview of the mathml layout logic I use
(note, same logic used in gtkmathview):

They layout and rendering is performed in several phases:
1: parsing / mathml dom tree building
2: generate an 'area' tree from the dom tree
3: fit the 'area' tree to a given size and re-organize the are tree
4: draw to a surface

The first phase is parsing the document and loading it into dom. This phase 
is
not really interesting, essentialy, the existing XmlReader (sax parser) just
calls the MathMLDocument class for each xml element encountered, and the
MathMLDocument creates mathml elements that are then stuffed in the dom 
tree.
This phase just builds a straight dom representation of the mathml source, 
there
is no layout information yet.

Then the first intresting bit happens, create an Area tree from the dom tree
An 'Area' is a node in a single rooted a-cyclic graph. An area can have
numerous child elements, however each child element is not aware of its
parent element. An area represents a rectangular region, it maintains a 
state
of width, height and depth, but does not keep the x-y location of this area.
The location of the area is computed each time the tree is drawn.

Areas are fairly simple, there are terminal areas such as glyph areas, and
container areas such as horizontal and vertical areas, these contain either
a horizontal or vertical stack of child areas.

An area tree is generated from the dom tree. Each source mathml dom element
recursivly generates a collection of areas. A good example is the mathml row
element. This element represents a horizontal row of elements. In this case,
lest assume each child dom element of the row element is either a glyph or a
identifier / operator such as '+', '1', 'xyz', etc. So, the mrow dom element
would be visited, a horizontal area would be created, then each child dom
element of the 'mrow' would be visited, each one would return a area, then
each child area would then be inserted into the horizontal area element, and
this element would then be returned. Now, between each child area that is
inserted into the horizontal area, a 'Filler Area' is inserted. This is an
area that can stretch to fill an empty region. This is used when the area
tree is fitted into a given region.

So at now we have a tree if areas and filler areas, we then ask it to 'fit'
to a given size. We call the 'Fit' method with a bounding box of the size
we want to fit to. at this point, each filler area returns a space area
that coresponds to this size it is asked to fit to.

Now we have a layed out area tree and are ready to render it. We call the
render method with a rendering context (QPainter type thing to draw to) and
a x / y coordinates representing the origin of that area where it should 
draw
to. Each container area calls each child area with an updated set of
origin coordinates where it should draw itself.

I have been looking into the khtml::RenderObject, this is the base object of 
the
kthml rendering tree. My current thought is that one way of integrating
mathml support into khtml is to create a collection of mathml specific
RenderObject derived classes to create a mathml rendering tree. This 
approach
would I think seemlessly intgrate mathml into khtml. I however am not very
familier with the code base, and I'm not sure of what kind of issues this 
approach
might present.

If anybody thinks this approach is good, is stupid, etc... please let my 
know
and we can work out a better approach.