> > That's pretty much the way I read it. If you can come up > > with an idea that allows for all the different viewers at > > all the different resolutions while still not having the > > Palm parse and layout the table, I'm all ears. ;) > I won't apologize for being a bad explainer, but, I already > did.
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 (unless I wanted all my tables to be 160-pixels wide ;). > Given the information in the table doc, the palm draws Okay, but please think about the other viewers out there. How will they handle it? This needs some thought before we can adopt your proposal. Also, if I replace the standard font with a larger or a smaller font, then the pixel heights will be incorrect, unless you've got a way to correct for that. (Have all the measurements in terms of line-height?) Similarly, if I'm using a wider font, then some words might wrap, and draw on the next line, making the heights of the cells incorrect, even if the font-height was the same. All these problems lead me to believe that we can't specify heights for table-rows, and also make it very hard to pre-calculate widths for columns, so I've come to the conclusion that those calculations will have to be done at runtime. > I don't know how you would want to handle it on a device > with a larger screen, but, I'd suspect the same way large > images are handled. How are large images handled? David? Anyone? Does the parser automatically scale things down to 160x160, or is it a config option? Could we use a similar config option for tables? Perhaps with a scaled version and an unscaled version? > > I should probably let you all know that I've written an > > HTML Parser for the Palm for my company. > I'd be interested is seeing that. That could be a problem, since it's not released as part of any of our products. It was more of a "Can we do this?" thing. > and how fast it renders on a real palm. That I can answer. Slowly. The rendering isn't so bad, but the initial parsing of the html is pretty slow. And I don't handle most of the html spec (certainly far less than plucker, and I don't handle images), which makes my job a whole lot easier. The way I did it for work was to parse the elements and content into a list of DataNodes, each of which had some flags indicating how to draw, and possibly some content. Then, I iterate through the nodes, drawing the content, wrapping where I have to. And since I already know the widths of the columns, I just set my bounds, and draw each table node within the bounds I've set for it. I keep note of the longest column within a row, and increment my y-value by that before I draw the next row. The drawing is not too slow, and I'm happy with it, given that it is the first HTML renderer I've ever written. (I didn't even use ideas from anywhere else. Well, not that I know of, anyways.) Later, Blake. _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
