You are not logged in Log in Join
You are here: Home » Members » jim » StructuredTextWiki » StructuredTextTables » wikipage_view

Log in


FrontPage » StructuredTextNG » NGRuleProposals »


The current rule for tabs

A paragraph that has blocks of text enclosed in || is treated as a table. The text blocks correspond to table cells and table rows are denoted by newlines. By default the cells are center aligned. A cell can span more than one column by preceding a block of text with an equivalent number of cell separators ||. Newlines and | cannot be a part of the cell text. For example:

    |||| **Ingredients**    ||
      || *Name* || *Amount* ||
      ||Spam    || 10       ||
      ||Eggs    || 3        ||

This is interpreted as:

      <TD ALIGN=CENTER COLSPAN=2> <strong>Ingredients</strong> </TD>
      <TD ALIGN=CENTER COLSPAN=1> <em>Name</em> </TD>
      <TD ALIGN=CENTER COLSPAN=1> <em>Amount</em> </TD>

Suggestions for changes?

John Odom says

maybe all paragraphs between two || should be considered tables rows. To divide paragraphs into columns, a single | could be used. For example:

    this is row 1
    this is row2 column1 | this is row2 column2
    this is row 3

should be outputed as:

      <td><p>This is row 1</p></td>
      <td><p>This is row2 column 1</p></td>
      <td><p>This is row2 column 2</p></td>
      <td><p>This is row 3</p></td>

I would also like to see a way of indicating column span. Perhaps at the end of a paragraph have a number in parathesis. Or if there is only whitespace after a | have that column swallowed by the preceding column.

Jim --

I want a table format that looks like a table that I would include in an email. Like this:

     Name      Favorite Color
      Jim         Red
      John        Blue  

That might take too much guessing, so something like the following might be better:

     |  Name   | Favorite       |
     |         | Color          |
     | Jim     |  Red           |
     | John    |  Blue          |


     | Function  | Documentation                       |
     | '__str__' | This method converts the            |
     |           |  the object to a string.            |
     |           |                                     |
     |           | - Blah                              |
     |           |                                     |
     |           | - Blaf                              |
     |           |                                     |
     |           |       |--------------------------|  |
     |           |       |  Name   | Favorite       |  |
     |           |       |         | Color          |  |
     |           |       |==========================|  |
     |           |       | Jim     |  Red           |  |
     |           |       |--------------------------|  |
     |           |       | John    |  Blue          |  |
     |           |       |--------------------------|  |

These look like tables, dang it. Remember, the goal of ST is to avoid markup that looks like markup!

Another Suggestion

I agree with the last remark, that we should avoid markup that looks like markup. But I think that the amount of ASCII linedrawing required for the last example would become cumbersome. I propose that we implement (possibly in addition to the previous) a way for the StructuredTextNG renderer to make colspan decisions based upon the character column number of the double pipes. I also would like to eliminate extraneous double pipes. Table cells would be broken up based upon which sets of pipes "line up" vertically. For example:

  ||              **Project Status**           ||
  || *My Projects*        || *Team Projects*   ||
  || Project One   || 15% || Project A || 100% ||
  || Project Two   || 50% || Project B ||  10% || 

...Should render as:

|||||||| Project Status || |||| My Projects |||| Team Projects || || Project One || 15% || Project A || 100% || || Project Two || 50% || Project B || 10% ||

Or, as a variation on the previous poster's first idea that might eliminate some of the guesswork: For simple, clean tables, table columns might be determined, again, by examining the character column number of a token character on the dividing line. (In this example, a single space character.) My previous table might now be described like this:

                 **Project Status**
  ----------------------- ------------------------
   *My Projects*           *Team Projects*
  ----------------- ----- ----------------- ------
   Project One       15%   Project A         100%
   Project Two       50%   Project B          10%

And the previous poster's "simple table" might look like this:

  ========= ================
   Name      Favorite Color
  --------- ----------------
   Jim       Red
   John      Blue  

...Which would render as:

|| Name || Favorite Color || || Jim || Red || || John || Blue ||

I would imagine that this should not be too hard to implement... I can forsee defining a paragraph as a table if it begins with a line consisting only of = and the token character. Heck, I could probably write this functionality myself even being a python newbie. --datagrok (Mike Lamb)

Yet Another Suggestion

Most tables (I would guess 90%) are simple tables. I think that the simpler these tables can be represented, the better. Especially when the tables need to be changed, this should be simple. The use of || would make the editing difficult. Therefore I very much like the last 2 examples without the ||.

I would want to suggest an even simpler (only for clean simple tables) solution:

Use tabs as column separators. A line that begins with 1 or more non-tabs followed by a tab automatically becomes the first row of a table. The last example would look like:

    Name      Favorite Color
    Jim       Red
    John      Blue  

The space in between would have to be tabs. Because I can't see another use for tabs in between text, this could work just for tables. Multiple tabs wouldn't be a problem either. (Martin)

gvanrossum (Mar 29, 2001 6:05 pm; Comment #1)
Can somebody explain why the line ||Eggs||3|| appears in a larger, bold font? it is entered exactly the same as the ||Spam||10|| line before...
simon (Jul 11, 2001 5:59 pm; Comment #2)
Yes - the following line ("is interpreted as") was indented, causing the eggs line to be treated as a heading.
datagrok (Jul 17, 2001 1:58 am; Comment #3)

Since the ASCII line-drawing tables functionality has already been implemented as what seems to be the New Way To Do It for StructuredTextNG, I'd suggest browsing Customizing The Document Processor , which should show us how to implement our ideas as extensions to the existing rules. That way, people have their pick of how to do things.

ElviX? (Sep 21, 2001 8:10 am; Comment #4-7)
output should be changed to lowercase , to comply with XHTML standards.
bkc (Nov 16, 2001 2:32 pm; Comment #8)
I've tweaked DocumentClass and HTMLClass to allow the specification of table attributes in the STX text. I realize this breaks the idea of presentation, but I really needed a way to turn off borders in my tables and control padding.

I use this re. match now in DocumentClass:

  expr = re.compile(r'\s*\|[-]+(?:htmlattr:(?P<htmlattr>.*)-)?[-]+\|').match

So I can insert html specific attributes as:

  |-----htmlattr:border="0" cellspacing="0" cellpadding="0"----|

I really wish there was a better way to express this.. Any better suggestions?

dhart (Nov 17, 2001 2:29 am; Comment #9)
For cell padding and border options, how about some combination of pipes and colons?

Like this:

    :|              **Project Status**           |:
    :| *My Projects*        || *Team Projects*   |:
    :| Project One   || 15% || Project A || 100% |:
    :| Project Two   || 50% || Project B ||  10% |:

datagrok (Nov 28, 2001 5:55 pm; Comment #10)
Controlling padding and borders? Use CSS!

If you don't want to use CSS and still need more precise control over the html-specific (!) attribute tags in the rendered tables, then you're getting more into the realm of presentation than data exchange. Remember, STX renders out into many different formats besides HTML. So it's likely that StructuredText isn't the proper data transport medium for what you're trying to do with it.

The data and the presentation should be kept separate so that the data may be more easily exchanged, and a Cascading Style Sheet, say, in your standard_html_header is a perfect way to do that. Mixing data and presentation only turns StructuredText into a slightly syntactically different HTML.

Here's an example:


Wow, cool.

A borderless table.

Imagine that! Neat, eh?

Should render as:

|| Wow, cool. || A borderless table. || |||| Imagine that! Neat, eh? ||

I didn't use any HTML to build that table. Check out the source on this comment. :-)

almt (Apr 13, 2002 3:22 pm; Comment #11)
It would be nice if blank cells could be converted into nbsp. Otherwise we end up with some borderless cells.
djay (Apr 29, 2002 9:48 pm; Comment #12) Editor Remark Requested
It maybe too late but here is an alternative suggestion.

A table could be represented as a two-tier list eg:

  - RowTable

   - Name 

    - Favorite Color

   - Jim

    - Red           

   - John

    - Blue 

or alternatively:

  - ColTable

   - Name 

    - Jim

    - John

   - Favorite Color

    - Red           

    - Blue

The advantages of this approach is that the meaning is clear from the text of the page (ie not too markupy) and it's easy to turn a list into a table or to rotate a table. It is still hard to create a new row in a ColTable? or a new col in a RowTable?, but at least you get to choose which one is hard.

Not sure about how to do spanning. Perhaps a only the last cell in a row or col can be spanned? djay (May 8, 2002 7:53 pm; Comment #13) -- I thought of another variation of the tree list idea. Col, Row labels would make maitanance even easier. eg

  • ColTable?
    • Name
      • jim -- Jim
      • john -- John
    • Favorite Color
      • jim -- Red
      • john -- Blue

would produce the same table

I have been using the TWiki? at for about three years now. They have some interesting ideas about how to support a plain text representation for common HTML constructions. Take a look at their text formatting rules. It might save some time in the discussions.

On a side note, the use of the plain text representations in one concern that I am thinking about when cosidering moving from TWiki? to ZWiki since I have quite a few pages in the TWiki? world. But I like a number of the capabilities of Zope and Zwiki as well.