home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 5 Edit / 05-Edit.zip / wvhtm064.zip / notes / tables < prev    next >
Text File  |  2000-09-02  |  3KB  |  66 lines
  1. Ive been plinking around with tables in the wv library at the moment, and
  2. have hacked together a few mechanisms (for simple mode only so far) to mangle
  3. them into a sensible arangement. Heres the story so far...
  4.  
  5. There is no concept of a table at all, there is only that of rows. So in
  6. advance there is no way of telling how many rows there are, or which cells
  7. will be merged into other ones, you can only tell when you actually get to
  8. the row in question. This is terribly awkward so i have installed a two
  9. pass system into wv.
  10.  
  11. On first finding a cell i loop through all the up and coming paragraphs 
  12. filling in some table details until i find a para that is not a table 
  13. or i hit the end of the document. this is wvGetFullTableInit
  14.  
  15. I keep two seperate numerical structs to keep track of some vital details,
  16. both tuned to the needs of a html converter. Firstly keeping track of
  17. colspanning, For instance take this example of a word table
  18.  
  19. -------------------------
  20. |          |            |
  21. -------------------------
  22. |   | | |    |     |    |
  23. -------------------------
  24. |                       |
  25. -------------------------
  26. |     |         |       |
  27. -------------------------
  28.  
  29. The html output should have a complex set of colspans to get the same layout as
  30. this, so i splurge the table into one row like this (wvSetTableInfo)
  31.  
  32. |   | | |  | |  |  |    |
  33.  
  34. So now given a cell and the boundaries that come with it (wvGetRowTap), i can 
  35. tell how many columns it crosses and assign that number to the colspan number, 
  36. and ta-da we get the same basic layout in html as we would in word.
  37.  
  38. The other issue is that of vertically merged cells, word says that it can only
  39. merge cells vertically if the boundaries match (whew !!, and then allows the
  40. bounds to differ by three units :-), anyhow not to grumble ), and sets the
  41. TC.fVertMerge member of the offending cell to 1. So again to munge this into
  42. html i create a 2dim array with a slot for each cell, and set each slot to 1
  43. (spans one row) I start at the bottom row of the table, and check to see if a 
  44. cell has vertmerge set, if so i check the cell whose boundaries are the same 
  45. on the above row (if it exists), if the above cell fits the profile we increment
  46. its colspan by the colspan of the cell on the under row (in this example 1), and
  47. then we set the under cell's colspan to 0 to indicate that we should not have a 
  48. reserved cell for this location at all. We continue up the table and the colspan
  49. figures percolate to the top so that when we output html we know in advance of 
  50. outputting a column or rows information all that we need to have for spanning
  51. in each dimension.
  52.  
  53. All nice enough, some issues that are a bit messy, and that impact abiword
  54. include
  55.  
  56. 1) doing wvGetFullTableInit in fastsaved mode will be a slight bit trickier
  57. 2) there is a special para consisting of just the row end mark, in my own
  58. binding to the PARABEGIN event i exclude this case from being a paragraph
  59. as it would just be an empty cell, 
  60. 3) when vertically merged cells exist there is an empty paragraph exactly
  61. the same as 2 in existance as well, I use my new entries in wvParseStruct
  62. to locate this event and to ignore starting a new paragraph for this
  63. event as well.
  64.  
  65. C.
  66.