[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [PATCH] org-html.el: Fix export of table.el tables.

From: Manuel Giraud
Subject: Re: [O] [PATCH] org-html.el: Fix export of table.el tables.
Date: Tue, 26 Apr 2011 17:14:36 +0200
User-agent: Gnus/5.1299999999999999 (Gnus v5.13) Emacs/23.3 (berkeley-unix)

Jambunathan K <address@hidden> writes:

> Our understanding matches. For the sake of clarity, here it is:
> For simple tables,
> 1. org-export-prefer-native-exporter-for-tables => Non-nil => Use the
>    HTML code generator in table.el => HTML *source code* has Lots of
>    &nbsp
> 2. org-export-prefer-native-exporter-for-tables => nil => Use Org's own
>    code generator => HTML *source code* is easy to look at.

Yes. The rendered HTML output is prettier with your patch. It is just
the HTML source that is full of &nbsp;. But now, I understand that it
comes from table.el.

> [snip]
> May be you are exporting a different table.el table? Can you post your
> example? 

No, I've used your example to test your patch.

> With point within a simple table.el-table, the elisp form down
> below should eval to false. Is it any different in your setting? 
> #+begin_src emacs-lisp
> (let* ((dim (table-query-dimension))
>        (c (nth 4 dim)) (r (nth 5 dim)) (cells (nth 6 dim)))
>   (not (= (* c r) cells)))
> #+end_src

Yes. It is false for simple table without spanning so I guess it's ok.

> It is possible that I have misunderstood how table-query-dimension API
> works ...

No, it's ok and it is my fault: I was worried about the complex HTML
output but now I understood that it is so for spanning table that are
rendered by table.el (and as I said I'm no HTML table expert so I guess
that table.el is the right thing when it comes to complex tables).

Manuel Giraud

reply via email to

[Prev in Thread] Current Thread [Next in Thread]