[webkit-dev] mathml support in webkit / khtml
Andy Somogyi
andy_somogyi at hotmail.com
Mon Jul 18 11:38:16 PDT 2005
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.
More information about the webkit-dev
mailing list