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.