* [odt/xhtml] Export lists as tables (list-tables)
@ 2011-09-01 19:31 Jambunathan K
2011-09-01 23:12 ` suvayu ali
2011-09-02 17:23 ` Nicolas Goaziou
0 siblings, 2 replies; 10+ messages in thread
From: Jambunathan K @ 2011-09-01 19:31 UTC (permalink / raw)
To: emacs-orgmode
[-- 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 --]
--
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [odt/xhtml] Export lists as tables (list-tables) 2011-09-01 19:31 [odt/xhtml] Export lists as tables (list-tables) Jambunathan K @ 2011-09-01 23:12 ` suvayu ali 2011-09-02 1:20 ` Matt Price 2011-09-02 17:23 ` Nicolas Goaziou 1 sibling, 1 reply; 10+ messages in thread From: suvayu ali @ 2011-09-01 23:12 UTC (permalink / raw) To: emacs-orgmode, Nathan Neff, Matt Price 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [odt/xhtml] Export lists as tables (list-tables) 2011-09-01 23:12 ` suvayu ali @ 2011-09-02 1:20 ` Matt Price 0 siblings, 0 replies; 10+ messages in thread From: Matt Price @ 2011-09-02 1:20 UTC (permalink / raw) To: suvayu ali; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [odt/xhtml] Export lists as tables (list-tables) 2011-09-01 19:31 [odt/xhtml] Export lists as tables (list-tables) Jambunathan K 2011-09-01 23:12 ` suvayu ali @ 2011-09-02 17:23 ` Nicolas Goaziou 2011-09-02 17:48 ` Matt Price 2011-09-03 8:44 ` Jambunathan K 1 sibling, 2 replies; 10+ messages in thread From: Nicolas Goaziou @ 2011-09-02 17:23 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [odt/xhtml] Export lists as tables (list-tables) 2011-09-02 17:23 ` Nicolas Goaziou @ 2011-09-02 17:48 ` Matt Price 2011-09-02 18:11 ` Nicolas Goaziou 2011-09-03 8:44 ` Jambunathan K 1 sibling, 1 reply; 10+ messages in thread From: Matt Price @ 2011-09-02 17:48 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [odt/xhtml] Export lists as tables (list-tables) 2011-09-02 17:48 ` Matt Price @ 2011-09-02 18:11 ` Nicolas Goaziou 2011-09-02 19:52 ` Thomas S. Dye 0 siblings, 1 reply; 10+ messages in thread From: Nicolas Goaziou @ 2011-09-02 18:11 UTC (permalink / raw) To: Matt Price; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [odt/xhtml] Export lists as tables (list-tables) 2011-09-02 18:11 ` Nicolas Goaziou @ 2011-09-02 19:52 ` Thomas S. Dye 0 siblings, 0 replies; 10+ messages in thread From: Thomas S. Dye @ 2011-09-02 19:52 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode@gnu.org 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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [odt/xhtml] Export lists as tables (list-tables) 2011-09-02 17:23 ` Nicolas Goaziou 2011-09-02 17:48 ` Matt Price @ 2011-09-03 8:44 ` Jambunathan K 2011-09-03 11:41 ` Nicolas Goaziou 1 sibling, 1 reply; 10+ messages in thread From: Jambunathan K @ 2011-09-03 8:44 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode 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.) -- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [odt/xhtml] Export lists as tables (list-tables) 2011-09-03 8:44 ` Jambunathan K @ 2011-09-03 11:41 ` Nicolas Goaziou 2011-09-03 12:58 ` Christian Moe 0 siblings, 1 reply; 10+ messages in thread From: Nicolas Goaziou @ 2011-09-03 11:41 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [odt/xhtml] Export lists as tables (list-tables) 2011-09-03 11:41 ` Nicolas Goaziou @ 2011-09-03 12:58 ` Christian Moe 0 siblings, 0 replies; 10+ messages in thread From: Christian Moe @ 2011-09-03 12:58 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode +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, > ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-09-03 12:57 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-01 19:31 [odt/xhtml] Export lists as tables (list-tables) Jambunathan K 2011-09-01 23:12 ` suvayu ali 2011-09-02 1:20 ` Matt Price 2011-09-02 17:23 ` Nicolas Goaziou 2011-09-02 17:48 ` Matt Price 2011-09-02 18:11 ` Nicolas Goaziou 2011-09-02 19:52 ` Thomas S. Dye 2011-09-03 8:44 ` Jambunathan K 2011-09-03 11:41 ` Nicolas Goaziou 2011-09-03 12:58 ` Christian Moe
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).