---Reply to mail from Blake Winton about Tables Conversion
> How do you know the size of the table?
> (I don't think that the parser can calculate it, particularly
> the height of the table.)
I'm thinking that would be part of the Table-document. The parser
would supply it based on it's 'rendering' for the table.
> (And when I say that my default font is really large,
> what I mean is that I'm using FontHack to replace the
> standard font with a larger one. If you assume that
> you know what the font-height and widths are, it'll
> break. If you get the height and widths, the program
> will work just fine.)
I hadn't thought about non-standard fonts. We could allow the user to
specify (like we do link color and bit depth) with a --table-font X (our
font #) if it's not the 'standard one (i.e. large-bold)
and --table-font-size 18x12 to tell the parser the size of the font. (?)
> I also wonder about backwards compatibility. How would
> older viewers handle this format? Would they ignore the
> formatting codes, and just draw the content? Could we
> add in tags for older viewers that the new viewer would
> be smart enough to ignore?
That's what I'm thinking the parser would insert the (thick or thin)
horizontal rules at the same places it does now, and the 'table-rendering
code would ignore them. The 'document-renderer' already ignores function
codes it doesn't know and would skip the table ones. So the old viewers
would render the table like they do now. That would also allow the viewer
a choice on how to have the device display the table (old or new style).
> I also quite like your idea of treating the table the same
> way we treat images (with small versions inline, and links
> to larger scrollable versions). But I wonder how we could
> handle links in that case. It might be tricky.
I'm pretty sure we couldn't put links in the table, but, the parser
could add the links after the 'small version' in the document that contained
the table. Perhaps a 'small version' showing the proper cell arrangement and the 'link'
cells colored in. The added benefit would be that you could select the link
without having to show (and possibly scroll) the table.
> (I'm not going to be at work this weekend, so if you could
> copy your reply to me at home, I would appreciate it.
> [EMAIL PROTECTED])
Done <G>
> Once again, it seems that most of the miscommunication is
> because I didn't understand your original proposal. I'm
> sorry, and do not intend any of my posts as attacks, just
> as explorations of how we can best fit tables into Plucker.
No problem!! I can visualize things a lot better than I can explain
them. I think the older^H^H^H^H^H long-time members understand that.
---End reply
Christopher R. Hawks
HAWKSoft
-------------------------------------------------------------------------
Security and MicroSoft :
"Bringing the world to your desktop - and your desktop to the world"
"The name doesn't go on until the insecurity goes in"
-- Peter Gutmann
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
