[odt/xhtml] Export lists as tables (list-tables)

[odt/xhtml] Export lists as tables (list-tables)

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 2478 bytes --]


I am pleased to announce support for list-tables in the odt/xhtml
exporters. See below for some introductary note. Also refer to the
attached org/odt/html files.

Thanks for your past and future inputs.
Jambunathan K.


Related posts:

1. Thanks to Ben for introducing list-table in this post
https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg01101.html

2. Thanks to Nathan Neff for raising the topic of resumes in the context
   of odt exporter
https://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg00998.html

Discussions with him led me to understand the "two column" style of
resumes. (Visibly speaking) the Eurpass CV template linked to below is
also "pre-dominantly" a two column format save for few rows which have
multiple columns.

http://europass.cedefop.europa.eu/img/dynamic/c1624/type.FileContent.file/CVTemplate_en_GB.odt

3. Thanks to Matt Price for passing complex table by me and registering
   some use cases.
https://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg01186.html

The overarching theme in all these threads is a multi-column table with
copious text where each column is variably sized.

List-tables is a humble first step in this direction. (Proportional
sizing of columns and support for grid lines is coming soon)

From the blurb:
,----
| ;; Notes on LIST-TABLES
| ;; ====================
| ;; When `org-lparse-list-table-enable' is non-nil, the following list
| ;;
| ;; #+begin_list-table
| ;; - Row 1
| ;;   - 1.1
| ;;   - 1.2
| ;;   - 1.3
| ;; - Row 2
| ;;   - 2.1
| ;;   - 2.2
| ;;   - 2.3
| ;; #+end_list-table
| ;;
| ;; will be exported as though it were a table as shown below.
| ;;
| ;; | Row 1 | 1.1 | 1.2 | 1.3 |
| ;; | Row 2 | 2.1 | 2.2 | 2.3 |
| ;;
| ;; Note that org-tables are NOT multi-line and each line is mapped to
| ;; a unique row in the exported document.  So if an exported table
| ;; needs to contain a single paragraph (with copious text) it needs to
| ;; be typed up in a single line. Editing such long lines using the
| ;; table editor will be a cumbersome task.  Furthermore inclusion of
| ;; multi-paragraph text in a table cell is well-nigh impossible.
| ;;
| ;; LIST-TABLEs are meant to circumvent the above problems with
| ;; org-tables.
| ;;
| ;; Note that in the example above the list items could be paragraphs
| ;; themselves and the list can be arbitrarily deep.
| ;;
| ;; Inspired by following thread:
| ;; https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg01101.html
`----


[-- Attachment #2: list-tables.org --]
[-- Type: text/plain, Size: 1190 bytes --]

#+TITLE:     list-tables.org
#+AUTHOR:    Jambunathan K
#+EMAIL:     kjambunathan@gmail.com
#+DATE:      2011-08-30 Tue
#+DESCRIPTION:
#+KEYWORDS:
#+LANGUAGE:  en
#+OPTIONS:   H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS:   TeX:t LaTeX:dvipng skip:nil d:nil todo:t pri:nil tags:not-in-toc

#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport
#+LINK_UP:   
#+LINK_HOME: 
#+XSLT:

* List Tables1
  A normal list

  - a
  - b
  - c

* List Table 2

  A homogenous list-table

#+begin_list-table
- Row 1
  - Row 1.1
  - Row 1.2
  - Row 1.3
- Row 2
  - Row 2.1
  - Row 2.2
  - Row 2.3
#+end_list-table

* List Table 3
  
  A degenerate list-table

#+begin_list-table
- Row 1
- Row 2
- Row 3
#+end_list-table

* List Table 4

  A non-homogenous list-table

#+begin_list-table
- Row 1
  - Row 1.1
  - Row 1.2
  - Row 1.3
- Row 2
  - Row 2.1
- Row 3
  - Row 3.1
  - Row 3.2
#+end_list-table

* List Tables 4
  A complex true-to-the-spirit multiline list-table

#+begin_list-table
- Row 1
  - Row 1.1
    - Subitem under 1.1
    - Yet another subitem under 1.1
  - Row 1.2
  - Row 1.3
- Row 2
  - Row 2.1
  - Row 2.2

    Subtext for 2.1
  - Row 2.3
#+end_list-table


[-- Attachment #3: list-tables.html --]
[-- Type: text/html, Size: 6974 bytes --]

[-- Attachment #4: list-tables.odt --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 8611 bytes --]

[-- Attachment #5: Type: text/plain, Size: 5 bytes --]


-- 

Re: [odt/xhtml] Export lists as tables (list-tables)

[suvayu ali]

Hi Jambunathan,

On Thu, Sep 1, 2011 at 9:31 PM, Jambunathan K <kjambunathan@gmail.com> wrote:
> I am pleased to announce support for list-tables in the odt/xhtml
> exporters. See below for some introductary note. Also refer to the
> attached org/odt/html files.
>
> Thanks for your past and future inputs.
> Jambunathan K.


Absolutely blown away by the features you keep on adding to org and
org-odt! I can confidently say everyone on the list will agree your
contributions have been invaluable. :)

On a more serious note, I'll try to find time this weekend to test things out.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [odt/xhtml] Export lists as tables (list-tables)

[Matt Price]

On Thu, Sep 1, 2011 at 7:12 PM, suvayu ali <fatkasuvayu+linux@gmail.com> wrote:
> Hi Jambunathan,
>
> On Thu, Sep 1, 2011 at 9:31 PM, Jambunathan K <kjambunathan@gmail.com> wrote:
>> I am pleased to announce support for list-tables in the odt/xhtml
>> exporters. See below for some introductary note. Also refer to the
>> attached org/odt/html files.
>>
>> Thanks for your past and future inputs.
>> Jambunathan K.
>
>
> Absolutely blown away by the features you keep on adding to org and
> org-odt! I can confidently say everyone on the list will agree your
> contributions have been invaluable. :)
>
> On a more serious note, I'll try to find time this weekend to test things out.
>
> --
> Suvayu
>
> Open source is the future. It sets us free.
>

this looks awesome. not sure when I can test drive it properly but it
really makes a lot of sense for people like me, who sometimes use
tables merely as a formatting convention and not e.g. as a spreadsheet
or similar.  thanks once gain J!
m

Re: [odt/xhtml] Export lists as tables (list-tables)

[Nicolas Goaziou]

Hello,

Jambunathan K <kjambunathan@gmail.com> writes:

> List-tables is a humble first step in this direction. (Proportional
> sizing of columns and support for grid lines is coming soon)
>
> From the blurb:
> ,----
> | ;; Notes on LIST-TABLES
> | ;; ====================
> | ;; When `org-lparse-list-table-enable' is non-nil, the following list
> | ;;
> | ;; #+begin_list-table
> | ;; - Row 1
> | ;;   - 1.1
> | ;;   - 1.2
> | ;;   - 1.3
> | ;; - Row 2
> | ;;   - 2.1
> | ;;   - 2.2
> | ;;   - 2.3
> | ;; #+end_list-table
> | ;;
> | ;; will be exported as though it were a table as shown below.
> | ;;
> | ;; | Row 1 | 1.1 | 1.2 | 1.3 |
> | ;; | Row 2 | 2.1 | 2.2 | 2.3 |
> | ;;
> | ;; Note that org-tables are NOT multi-line and each line is mapped to
> | ;; a unique row in the exported document.  So if an exported table
> | ;; needs to contain a single paragraph (with copious text) it needs to
> | ;; be typed up in a single line. Editing such long lines using the
> | ;; table editor will be a cumbersome task.  Furthermore inclusion of
> | ;; multi-paragraph text in a table cell is well-nigh impossible.
> | ;;
> | ;; LIST-TABLEs are meant to circumvent the above problems with
> | ;; org-tables.
> | ;;
> | ;; Note that in the example above the list items could be paragraphs
> | ;; themselves and the list can be arbitrarily deep.
> | ;;
> | ;; Inspired by following thread:
> | ;; https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg01101.html
> `----

This will certainly be useful to many Orgers. Though, I will make
a remark on the technical side.

You shouldn't use blocks for this. Blocks are on the heavy side of
syntax and are to be avoided when possible. Here, Org is perfectly able
to determine list end by itself[1] without an explicit boundary.
Furthermore, blocks, with the obvious exception of backend specific
ones, are expected to do "something" in any major exporter. Thus, to put
things differently, the structure you use should mention, by one way or
another, that this is ODT specific.

Hence, I would suggest to use a line like:

                         #+attr_odt: list-table

just above the list instead of the current choice of syntax.

Now, as this file is meant to reach Org core, I really wish we can come
up with a more general solution that will benefit to every other
official export backend. Indeed, while developing one specific exporter
is very useful, I personally think that, on the other hand, we must aim
at providing users a consistent experience with any of them[2].

That being said, nice work.


Regards,

[1] with the following code, when point is at an item:
#+begin_src emacs-lisp
(org-list-get-bottom-point (org-list-struct))
#+end_src

[2] I will probably submit code soon that should help greatly in that
mission.

-- 
Nicolas Goaziou

Re: [odt/xhtml] Export lists as tables (list-tables)

[Matt Price]

hi Nicolas

On Fri, Sep 2, 2011 at 1:23 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hence, I would suggest to use a line like:
>
>                         #+attr_odt: list-table
>
> just above the list instead of the current choice of syntax.
>
> Now, as this file is meant to reach Org core, I really wish we can come
> up with a more general solution that will benefit to every other
> official export backend. Indeed, while developing one specific exporter
> is very useful, I personally think that, on the other hand, we must aim
> at providing users a consistent experience with any of them[2].

I think J's code handles both  xhtml &  odt exports; remember his
xhtml was originally developed as a possible basis for a new 'generic'
exporter. Given the goal of a general solution, why not just:

#+attr: list-table

with all the exporters aiming to support this feature if it ends up
being welcomed by the community as a whole.
>
> [2] I will probably submit code soon that should help greatly in that
> mission.

that sounds great, I really look forward to it and am glad to see so
many people working on the task of simplifying the creation and
management of the exporters!

Matt

Re: [odt/xhtml] Export lists as tables (list-tables)

[Nicolas Goaziou]

Hello,

Matt Price <moptop99@gmail.com> writes:

> I think J's code handles both  xhtml &  odt exports; remember his
> xhtml was originally developed as a possible basis for a new 'generic'
> exporter. Given the goal of a general solution, why not just:
>
> #+attr: list-table

Maybe when it will indeed be a general solution. But xhtml & odt isn't
enough for that yet.

Moreover, #+attr: keyword doesn't exist yet. I think we should
keep #+attr_ for backend specific stuff, there are so many keywords
available to choose from. For example, to be consistent with Babel,
there is #+header:.

Regards,

-- 
Nicolas Goaziou

Re: [odt/xhtml] Export lists as tables (list-tables)

[Thomas S. Dye]

Would it be useful to be able to name lists, perhaps so they can be passed to source code blocks just like tables?

Tom

Sent from my iPhone

On Sep 2, 2011, at 8:11 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
> 
> Matt Price <moptop99@gmail.com> writes:
> 
>> I think J's code handles both  xhtml &  odt exports; remember his
>> xhtml was originally developed as a possible basis for a new 'generic'
>> exporter. Given the goal of a general solution, why not just:
>> 
>> #+attr: list-table
> 
> Maybe when it will indeed be a general solution. But xhtml & odt isn't
> enough for that yet.
> 
> Moreover, #+attr: keyword doesn't exist yet. I think we should
> keep #+attr_ for backend specific stuff, there are so many keywords
> available to choose from. For example, to be consistent with Babel,
> there is #+header:.
> 
> Regards,
> 
> -- 
> Nicolas Goaziou
> 

Re: [odt/xhtml] Export lists as tables (list-tables)

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> List-tables is a humble first step in this direction. (Proportional
>> sizing of columns and support for grid lines is coming soon)
>>
>> From the blurb:
>> ,----
>> | ;; Notes on LIST-TABLES
>> | ;; ====================
>> | ;; When `org-lparse-list-table-enable' is non-nil, the following list
>> | ;;
>> | ;; #+begin_list-table
>> | ;; - Row 1
>> | ;;   - 1.1
>> | ;;   - 1.2
>> | ;;   - 1.3
>> | ;; - Row 2
>> | ;;   - 2.1
>> | ;;   - 2.2
>> | ;;   - 2.3
>> | ;; #+end_list-table
>> | ;;
>> | ;; will be exported as though it were a table as shown below.
>> | ;;
>> | ;; | Row 1 | 1.1 | 1.2 | 1.3 |
>> | ;; | Row 2 | 2.1 | 2.2 | 2.3 |
>> | ;;
>> | ;; Inspired by following thread:
>> | ;; https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg01101.html
>> `----

Hello Nicolas

Thanks for you feedback.

Long post. Intention is to record my notes on the topic as opposed to
responding/acting directly on your specific feedback. There is some
slight digression as well here and there.

Consider my implementation as a prototype and there is LOTS OF scope for
improvement including the possibility of abandoning it altogether and
settling instead for a most efficeint implementation. 

I implemented it mostly to exercise the org-lparse library a bit and
ended up extracting/abstracting few things in org-lparse.el.  Note that
I have zero understanding of list-struct. The list-tables are generated
right at the point where lists/list-items are emitted WITHOUT and I
DONOT DO any "pre-processing" on list-struct. I would consider this
approach as "backend-driven". This is in contrast, to the approach that
you have taken in

https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg01125.html

which is "frontend-driven".

Btw, having a prototype also helps in 
1. registering a clear intent
2. get some clarity on the points of interest

> You shouldn't use blocks for this. Blocks are on the heavy side of
> syntax and are to be avoided when possible.

Could you please clarify what exactly you mean by "heavy side" of
syntax?

> Here, Org is perfectly able to determine list end by itself[1] without
> an explicit boundary.  

There should be a way for the user to specify that "this" list is a
special kind of list and need to be exported differently. In some sense
identifying the beginning of a list-table is crucial. (As you rightly
note finding the end of the list is easy.)

These are some possibilities that I considered for declaring a
list-table and abandoned it mostly because it would require extra work.

1. Use the top-level bullet-type to identify special kinds of lists
   * Advantages
     - This theme occurred a few days ago in the thread "Convert list to
       Paragraph". See
       https://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg01117.html.

     - No special metalines required

   * Disadvantages
     - list-structs report only on three types of bullets - ordered,
       unordered, description - even though Org syntax recognize
       multiple kinds of bullets for the unordered (`-', `+', `*') and
       ordered (`1.', `1)'). As a result org-lparse driver has only a
       small catalogue of "list types" to work with as opposed to a
       greater set available to the front end driver.

       One of the things that could be considered is to enhance
       list-struct so that it starts reporting on various "kinds" of
       ordered and unordered and the not so commonly used bullet types
       (which is user-specific) could be reserved for special export
       processing. (I almost never use *, +, or alphabetical styles).

       A nice side-effect of such a enhancement would be that the
       backend drivers - like odt - can offer a platter of list styles
       that match one-to-one with the list style used in Org file
       resulting in a more richer export.

2. Use description list as leader lines. One of 

- ORG-LIST-TABLE :: ORG-LIST-TABLE-OPTIONS
  - a
    - b
  - c
    - d
  - e
    - f

- ORG-LIST-TABLE :: ORG-LIST-TABLE-OPTIONS
- a
  - b
- c
  - d
- e
  - f

> Furthermore, blocks, with the obvious exception of backend specific
> ones, are expected to do "something" in any major exporter. 

I am not sure by "doing something" you mean "create side-effects" like
generating results block. 

For now, I will assume that you are meaning "format it in a custom
manner" - by formatting it could mean plain formatting (list becomes
list), stripping (comment, src block etc stripped on export),
transforming (src block is appended or replaced with results block or a
ditaa block replaced with image file). With my latter definition,
"something" does happen though it happens to be "different things" for
different backends. I agree that this difference in behaviour amounts to
major incosistency and has to be bridged.

Let me explain.

The current implementation uses a custom implementation of
org-special-blocks.el but NOT org-special-blocks.el per se.

When org-special-blocks.el is NOT LOADED, 
- For lparse backends, "something" => list->table conversion
- For non-lparse backends, "something" => list->list

When org-special-blocks.el is LOADED
- for latex, ORG-LIST-TABLE-START and ORG-LIST-TABLE-END will be
  inserted in the buffer and later transformed
  to \begin{list-table}...\end{list-table} directive. This is a bug and
  has to be addressed. I think org-special-blocks.el has to be modified
  someway so that list is emitted normally.
- for html backend, the list will be surrounded with a <div > </div>
- for docbook backend, the list will be emitted normally
- for lparse-backends, the list->table conversion will happen.

> Thus, to put things differently, the structure you use should mention,
> by one way or another, that this is ODT specific.

list->table conversion will happen only if
`org-lparse-list-table-enable' is enabled (the default being disabled -
since it is an experimental/new feature). 

May be I could modify org-special-blocks.el to do capture something like
this [1]

'(LIST-TABLE
  (LATEX DO-NOTHING) ;; don't put in special env
  (HTML DEFAULT-ACTION) ;; surround with <div/>
  (DOCBOOK DO-NOTHING)
  (ODT CUSTOM-ACTION) ;; leave what to do the exporter
  (XHTML DEFAULT-ACTION)) 

and have the user customize it before using list-tables feature. This
way he will atleast know that list-tables are plain lists in non-lparse
backends.

> Hence, I would suggest to use a line like:
>                          #+attr_odt: list-table
>
> just above the list instead of the current choice of syntax.

I have not considered this.

Retrospectively speaking, Captions, labels and attributes gets applied
only to tables and links (IIRC) and not LISTS. [2]

When lists are emitted as tables, one might want to attach styles to the
list-table as though it were a table. So support for applying
attr_whatever to list will become necessary.

May be it is just not attr_odt or attr_html but instead attr_lparse?

> Now, as this file is meant to reach Org core, I really wish we can come
> up with a more general solution that will benefit to every other
> official export backend. Indeed, while developing one specific exporter
> is very useful, I personally think that, on the other hand, we must aim
> at providing users a consistent experience with any of them[2].

I agree with consistency part.

> [2] I will probably submit code soon that should help greatly in that
> mission.

That will be good or even better.

Thanks.
Jambunathan K.

[1] There should be a way to attach a custom handler for a special block
and it could also take some params.

In the below thread,
https://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg01267.html

it surfaced that 

#+begin_todo additonal-params
todonotes
#+end_todo

could be emitted as macro and not as environment (I may have got my
LaTeX terms wrong)

[2] Speaking of attributes, as a side note, there is clearly an INTENT
to apply captions etc to source blocks and examples. But due to
historical reasons there has been a re-ordering of processing steps in
org-export-preprocess-string which to leads to loss of the caption
information. (I have seen requests for having captions in src blocks
etc.)





-- 

Re: [odt/xhtml] Export lists as tables (list-tables)

[Nicolas Goaziou]

Hello,

Jambunathan K <kjambunathan@gmail.com> writes:

> I implemented it mostly to exercise the org-lparse library a bit and
> ended up extracting/abstracting few things in org-lparse.el.  Note that
> I have zero understanding of list-struct. The list-tables are generated
> right at the point where lists/list-items are emitted WITHOUT and I
> DONOT DO any "pre-processing" on list-struct. I would consider this
> approach as "backend-driven".

That's exactly my point. This is backend specific.

> This is in contrast, to the approach that you have taken in
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg01125.html
>
> which is "frontend-driven".

I wouldn't call this quick hack an "approach". In fact, as an approach,
it would be quite bad: you're right, it's all an exporter thing, not an
Org one.

> Btw, having a prototype also helps in 
> 1. registering a clear intent
> 2. get some clarity on the points of interest

Agreed.

>> You shouldn't use blocks for this. Blocks are on the heavy side of
>> syntax and are to be avoided when possible.
>
> Could you please clarify what exactly you mean by "heavy side" of
> syntax?

Block syntax is very intrusive in an Org document. Unless there's one
really good reason to use it, we shouldn't.

Now, the only valid reason I see to use a block in that case is that it
allows to have a table-list within a list, which is a bit convoluted.

> There should be a way for the user to specify that "this" list is a
> special kind of list and need to be exported differently. In some sense
> identifying the beginning of a list-table is crucial. (As you rightly
> note finding the end of the list is easy.)

That's why I talked about #+attr_odt.

> These are some possibilities that I considered for declaring a
> list-table and abandoned it mostly because it would require extra work.
>
> 1. Use the top-level bullet-type to identify special kinds of lists
>    * Advantages
>      - This theme occurred a few days ago in the thread "Convert list to
>        Paragraph". See
>        https://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg01117.html.
>
>      - No special metalines required
>
>    * Disadvantages
>      - list-structs report only on three types of bullets - ordered,
>        unordered, description - even though Org syntax recognize
>        multiple kinds of bullets for the unordered (`-', `+', `*') and
>        ordered (`1.', `1)'). As a result org-lparse driver has only a
>        small catalogue of "list types" to work with as opposed to a
>        greater set available to the front end driver.
>
>        One of the things that could be considered is to enhance
>        list-struct so that it starts reporting on various "kinds" of
>        ordered and unordered and the not so commonly used bullet types
>        (which is user-specific) could be reserved for special export
>        processing. (I almost never use *, +, or alphabetical styles).
>
>        A nice side-effect of such a enhancement would be that the
>        backend drivers - like odt - can offer a platter of list styles
>        that match one-to-one with the list style used in Org file
>        resulting in a more richer export.
>
> 2. Use description list as leader lines. One of 
>
> - ORG-LIST-TABLE :: ORG-LIST-TABLE-OPTIONS
>   - a
>     - b
>   - c
>     - d
>   - e
>     - f
>
> - ORG-LIST-TABLE :: ORG-LIST-TABLE-OPTIONS
> - a
>   - b
> - c
>   - d
> - e
>   - f

I really think this is the wrong direction to go anyway.

Org syntax is meant for... Org. Almost every syntactical element should
provide information to _Org_ that cannot be provided by others means.
Only exceptions allowed are elements whose boundaries need to be
explicitly specified. In that case, a block structure in indeed the Org
way to answer their needs.

Obviously, #+begin_center, #+begin_verse, and the logic behind
org-special-blocks.el are these exceptions.

list-tables are, from Org, just lists. They may be exported differently
(more exactly their first two levels may be), but they're still lists.
A well-defined syntax exists for them, and there is no need to re-invent
the wheel.

You want to tell some exporter(s) that the list should be treated
differently. There's a way: "#+attr_(backend)".

> Retrospectively speaking, Captions, labels and attributes gets applied
> only to tables and links (IIRC) and not LISTS. [2]

This is being worked on. From my point of view, almost everything could
have caption, label and attributes. More on that later.

> May be it is just not attr_odt or attr_html but instead attr_lparse?

attr_lparse means nothing for the non-developer. An user knows the
output format he wants to get, not the parser internally used to provide
it.

Moreover, no offense to take, I really wish we can get rid of such
a thing as org-lparse.el. For all its benefits, it's still the spawn of
evil: org-html.el.

Parsing line after line a block driven format is just unnatural. We can
do better.

> In the below thread,
> https://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg01267.html
>
> it surfaced that 
>
> #+begin_todo additonal-params
> todonotes
> #+end_todo
>
> could be emitted as macro and not as environment (I may have got my
> LaTeX terms wrong)

In my opinion, any block could have the Babel-oriented following syntax,
where anything between parenthesis is clearly optional:

(#+caption: caption)
(#+label: label)
(#+attr_backend: backend specific params)
(#+header: generic params)
#+begin_name (generic params)
...
#+end_name

The optional lines could be in any order, #+attr_backend and #+header
line could happen any number of times.

Regards,

-- 
Nicolas Goaziou

Re: [odt/xhtml] Export lists as tables (list-tables)

[Christian Moe]

+1 for extending caption, label and attributes to more elements. Nice 
to know it's being worked on.

Yours,
Christian

On 9/3/11 1:41 PM, Nicolas Goaziou wrote:
>
>> Retrospectively speaking, Captions, labels and attributes gets applied
>> only to tables and links (IIRC) and not LISTS. [2]
>
> This is being worked on. From my point of view, almost everything could
> have caption, label and attributes. More on that later.
(...)
> In my opinion, any block could have the Babel-oriented following syntax,
> where anything between parenthesis is clearly optional:
>
> (#+caption: caption)
> (#+label: label)
> (#+attr_backend: backend specific params)
> (#+header: generic params)
> #+begin_name (generic params)
> ...
> #+end_name
>
> The optional lines could be in any order, #+attr_backend and #+header
> line could happen any number of times.
>
> Regards,
>