First off, I'm getting the feeling that my post upset you. I wasn't intending it to have that affect, but re-reading my post I think that some of what I said might have come out as a personal attack. If you read it that way, I apologize.
> > Hmm... The way I understood your idea was that it relied on > > specific pixel positions, and so wouldn't work for my large > > GTK viewer. > I'll try one more time. The parser creates an offscreen window > the size of the table (which is not 160x160 except by coincidece). > --------------------- --- Ah, now I understand. But... 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.) > Then it draws the boxes (if border width was >0) and places > the text (as specifed font-size, color, etc) at the locations > shown in the document. > Think of it as verbal description of the table. This part I understand (well, kind of...) > Make image-window 1280x900 > Move to 0,0 > Make a box at 0,0 1280 x 50 pixels > Put RED Size 8 (our font numbers) "Periodic Table of the > Elements" at 472,16 Right. I get it. This is where I start to have the problem with your approach. My default font is really large, and so it doesn't fit in the box allocated for it. What will happen? If the table was parsed on the Palm, you could resize the box, but that wouldn't work if the sizing is done on the desktop. (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.) HTML doesn't specify the heights of table rows, and I think this is on purpose, since the heights can vary for a number of reasons. Could we remove the y-values from your proposal, and still have it make sense? So it would look something like this: ------------------------ Make image-window 1280xsomething large. Set current height to 0. Move to 0,current height Make the top of a box at 0,current height 1280 pixels wide Put RED Size 8 (our font numbers) "Periodic Table of the Elements" at 472, current height Make the bottom of the box at the new current height. (This would be like a </TR>.) Make the top of a box at 0,current height 55 pixels wide Put BLUE Size 7 "Hy" at 42,current height Put image (document #42) at 30,current height + 10 Put GREEN Size 6 "Hydrogen 1" at 35,current height + 30 Make the bottom of the box at the new current height. ... ------------------------ It would require the viewer to keep track of the current height, but that might not be too much of a burden. (I'ld have to ask someone more familiar with the viewer if it could be added in reasonably cleanly.) 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? > > The other viewers[...] > How the viewer deals with the image is the viewer's problem. Up to a point. I think that the format should make some attempts to be friendly to all viewers. 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 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]) 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. Later, Blake. _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
