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
