Don't forget to add in code in case the table is larger than the palm record limit. That could get fun.
--Wes ----- Original Message ----- From: "Bill Janssen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 31, 2002 9:16 PM Subject: Re: Tables Conversion > So let's try some design, using 0x90 as the function code base. > > BEGIN_TABLE: 0x97 ncols:1 width:1 talign:1 border:1 bg-color:3 > BORDER_COLOR: 0x93 border-color:3 > BEGIN_TABLE: 0x94 ncols:1 width:1 talign:1 border:1 > BEGIN_TR: 0x91 align:1 > BEGIN_TD: 0x92 align:1 colspan:1 > BEGIN_TD: 0x95 align:1 colspan:1 bg-color:3 > END_TABLE: 0x90 > > where > > cols = integer between 1 and 255 > width = integer between 0 and 100 (% of container width) > talign = left: 0, right: 1, center: 2 > border = integer between 0 and 255 (pixel width for border) > border-color = RGB triple > bg-color = RGB triple > align is ((halign << 2) | valign), where > halign = left: 0, center: 1, right: 2, justify: 3 > valign = top: 0, middle: 1, bottom: 2, baseline: 3 > colspan = integer between 1 and 255 > > BORDER_COLOR would only be used when a table had to be colored, and > would have to occur between the BEGIN_TABLE and the HORIZONTAL RULE > marking the start of the table. > > I'm tempted to define the "border" width in some absolute unit, like > 1/72 of an inch (OK, OK -- 1/3 mm), instead of in pixels. Something > that can be scaled appropriately for the display device. > > > > Perhaps we could just add a few more function codes, > > > TableRowBegin, TableRowEnd, TableDataBegin, TableDataEnd. > > > with the default TableRowBegin inserting a bold line, and > > > the default TableDataBegin inserting a narrow line. > > > > > > Then, the individual viewers could be updated to do > > > things with tables, if they thought they could handle it. > > > > Yes, that's what I was thinking of. The additional function codes > > would really be hints, though, and the current <HR> codes would also > > be there. Newer versions of the viewer could read the hint, and > > instead of displaying the embedded <HR>, would instead know where the > > table-row and table-column boundaries are, and could display the table > > more intelligently. Older versions of the viewer would continue to > > operate as they already do. > > > > > There should also be a TableStart and TableEnd codes, so that > > > we can have multiple tables one after the other without them > > > blending into a single table. As a further optimization, we > > > could include the number of columns as data for the TableStart > > > so that a naive implementation for the Palm could split the > > > screen into equally-spaced columns, and draw the contents for > > > each row into the (tiny) space given. > > > > Good ideas. > > > > Bill > > > > _______________________________________________ > > plucker-dev mailing list > > [EMAIL PROTECTED] > > http://lists.rubberchicken.org/mailman/listinfo/plucker-dev > > > _______________________________________________ > plucker-dev mailing list > [EMAIL PROTECTED] > http://lists.rubberchicken.org/mailman/listinfo/plucker-dev > _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
