(migrated from perl-qa) On Wednesday 01 August 2001 03:10 pm, David L. Nicol wrote: > "Bryan C. Warnock" wrote: > > I didn't have a good solution for tables, mainly because I didn't like a > > tab, comma, or pipe separated solution. (Which isn't intended as > > commentary on Ziggy.) > > Here's a possibility -- new rows are indicated by a flush-left line, > each column has a line. (this happens to be how I like to lay out > my <table><tr><td>data</td></tr></table> data.) > > Table of Students: > > Last Name > First Name > Exam Grade > Semester Grade > Cup Size > Aardvark > Chris > D > B > A > > > The thing might end at the first blank line. It's too awkward to read and write, particular if you have a lot of columns. I toyed with automatic column detection for a while - (convert any tabs to spaces, convert whitespace to 1s, non-whitespace to 0s, and & all the lines together. Splitting on /(1+)/ allows determination on each individual column width, as well as the space between columns. Then generate the appropriate format on the fly, and fill it in with the heavy use of substrs. It was supposed to allow table creation in the same vein as "I'll figure out what you're trying to do, just do it.", and it worked fairly well for me. Couldn't handle multiline entries, was my biggest problem. Then I realized that I was doing it all in a fixed width font, and the whole thing was worthless in the customer's WYSIWYG environment. But I digress...) I basically came to the conclusion that there was no real easy way to produce a table without resorting to input that makes you focus more on the table itself than the data you're putting in. And when it comes to documentation, the latter is much more important than the former. Unlike Ziggy, however, we didn't have a lot of tables to produce, so the customer was content with table production in a spreadsheet, which I could then process during page generation. Obviously, that won't work for POD, and I do feel that POD needs table support. -- Bryan C. Warnock [EMAIL PROTECTED]
