On Tue, Dec 25, 2001 at 11:49:08AM -0800, David A. Desrosiers wrote: > That being said, here's some of the issues with supporting tables > in the way you are requesting:
Thank you for this detailed explanation, David! Tables are my number one feature that AvantGo has and Plucker lacks; I've seen the "no horizontal scrollbar, ever" reason mentioned before, but that just made me wonder "why not support just sufficiently-narrow tables?". I have been contemplating trying to contribute to Plucker, and I'm glad I read this before I started. > 1.) Tables are computationally expensive. I'm going to have to read some code to see how tricky this would be, but the approach I was thinking of was along the lines of: parser "completes" the table, rationalizing missing HTML elements and presents an N-row by M-column data structure to the viewer. The viewer, on first presentation of a table (and after font changes), runs through the table and measures the minimum width of each cell (which is the width of the widest unbreakable unit in the cell). Also figure out maximum width of each cell. Take the column-wise maximum of each of the "min" results, and that's your minimum column widths. (I'm assuming that the parser has no knowledge of viewer font sizes) Add in some multiple of M-1 to put spaces between the columns. If the sum exceeds the width of the screen, your table is too big and can't be displayed (possible fallback: cut words into pieces, as you do with non-table words that are too long to fit on one line). If the sum is less, then distribute the spare pixels to each column width (and no need to make any column wider than its maximum element width). That doesn't sound like a ton of computation, although I admit I'm wholly ignorant of how expensive it is to do word break and measure word widths. But it does only have to be done once per table per font change. The rendering might be tricky if you have a tall cell and you are starting part-way through. Keeping all the cells in that row properly aligned might be hard, especially if the normal text presentation is done with high-level Palm system stuff (I guess I really do need to read some code!). I've glossed over tables within tables. It's possible to imagine tables of arbitrary complexity and size, but it sure would be nice if Plucker could just render stuff like: <table> <tr> <th>Flight</th><th>Time</th><th>Gate</th> </tr> <tr> <td>AC51</td> <td>10:15</td> <td>A12</td> </tr> <tr> <td>AA751</td> <td>11:15</td> <td>A17</td> </tr> <tr> <td>UA331</td> <td>14:12</td> <td>B6</td> </tr> </table>
