Ive been plinking around with tables in the wv library at the moment, and have hacked together a few mechanisms (for simple mode only so far) to mangle them into a sensible arangement. Heres the story so far... There is no concept of a table at all, there is only that of rows. So in advance there is no way of telling how many rows there are, or which cells will be merged into other ones, you can only tell when you actually get to the row in question. This is terribly awkward so i have installed a two pass system into wv. On first finding a cell i loop through all the up and coming paragraphs filling in some table details until i find a para that is not a table or i hit the end of the document. this is wvGetFullTableInit I keep two seperate numerical structs to keep track of some vital details, both tuned to the needs of a html converter. Firstly keeping track of colspanning, For instance take this example of a word table ------------------------- | | | ------------------------- | | | | | | | ------------------------- | | ------------------------- | | | | ------------------------- The html output should have a complex set of colspans to get the same layout as this, so i splurge the table into one row like this (wvSetTableInfo) | | | | | | | | | So now given a cell and the boundaries that come with it (wvGetRowTap), i can tell how many columns it crosses and assign that number to the colspan number, and ta-da we get the same basic layout in html as we would in word. The other issue is that of vertically merged cells, word says that it can only merge cells vertically if the boundaries match (whew !!, and then allows the bounds to differ by three units :-), anyhow not to grumble ), and sets the TC.fVertMerge member of the offending cell to 1. So again to munge this into html i create a 2dim array with a slot for each cell, and set each slot to 1 (spans one row) I start at the bottom row of the table, and check to see if a cell has vertmerge set, if so i check the cell whose boundaries are the same on the above row (if it exists), if the above cell fits the profile we increment its colspan by the colspan of the cell on the under row (in this example 1), and then we set the under cell's colspan to 0 to indicate that we should not have a reserved cell for this location at all. We continue up the table and the colspan figures percolate to the top so that when we output html we know in advance of outputting a column or rows information all that we need to have for spanning in each dimension. All nice enough, some issues that are a bit messy, and that impact abiword include 1) doing wvGetFullTableInit in fastsaved mode will be a slight bit trickier 2) there is a special para consisting of just the row end mark, in my own binding to the PARABEGIN event i exclude this case from being a paragraph as it would just be an empty cell, 3) when vertically merged cells exist there is an empty paragraph exactly the same as 2 in existance as well, I use my new entries in wvParseStruct to locate this event and to ignore starting a new paragraph for this event as well. C.
