[-- Attachment #1: Type: text/plain, Size: 4083 bytes --] Export to Latex (org-latex-export-to-pdf) generates incorrect latex when list items start with a left square bracket. This occurs because the \item command interprets the left square bracket as the start of an argument list. An example: An item list: - abc def - [def] ghi - [jkl m n o] - pqr This produces the latex fragment: An item list: \begin{itemize} \item abc def \item [def] ghi \item [jkl m n o] \item pqr \end{itemize} The pdf output renders the second and third items incorrectly. If there is no right bracket to terminate the argument, then pdf generation may fail with message: org-latex-compile: PDF file ./example.pdf wasn't produced: Runaway argument I fixed these cases in my local environment using defadvise on org-latex-item to wrap an initial left square bracket in braces. I used this form: (eval-after-load "ox-latex" '(progn (defadvice org-latex-item (after escape-initial-bracket activate) (setq ad-return-value (replace-regexp-in-string "\\\\item \\[" "\\\\item {[}" ad-return-value))))) This changes the latex fragment for the above example to: An item list: \begin{itemize} \item abc def \item {[}def] ghi \item {[}jkl m n o] \item pqr \end{itemize} This form renders PDF correctly. My knowledge of latex is very limited, I don't know if this is a reasonable approach or not. There appears to be one other function in the ox-latex.el generating the \item command: (org-latex-headline). I did not try to reproduce this case. ------------------------------------------------------------------------ Emacs : GNU Emacs 24.2.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2012-08-27 on bob.porkrind.org Package: Org-mode version 8.2.3c (8.2.3c-elpa @ /Users/jdegenhardt/.emacs.d/elpa/org-20131115/) current state: ============== (setq org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-occur-hook '(org-first-headline-recenter) org-metaup-hook '(org-babel-load-in-session-maybe) org-log-done 'time org-confirm-shell-link-function 'yes-or-no-p org-use-sub-superscripts '{} org-startup-indented t org-after-todo-state-change-hook '(org-clock-out-if-current) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-babel-pre-tangle-hook '(save-buffer) org-mode-hook '(#[nil "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes (lambda nil (turn-on-visual-line-mode) (turn-off-auto-fill))) org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-hide-inline-tasks org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-todo-keywords '((sequence "TODO" "STARTED" "ONHOLD" "|" "DONE" "CANCELED") ) org-latex-packages-alist '(("margin=0.75in" "geometry" nil)) org-confirm-elisp-link-function 'yes-or-no-p org-metadown-hook '(org-babel-pop-to-session-maybe) org-agenda-files '("~/Notes/General-Ongoing.org") org-clock-out-hook '(org-clock-remove-empty-clock-drawer) ) [-- Attachment #2: Type: text/html, Size: 7055 bytes --]
Hello, ** Jon Degenhardt [2014-01-11 13:18:29 -0800]: > Export to Latex (org-latex-export-to-pdf) generates incorrect latex when > list items start with a left square bracket. This occurs because the > \item command interprets the left square bracket as the start of an > argument list. An example: > An item list: > - abc def > - [def] ghi > - [jkl m n o] > - pqr > This produces the latex fragment: > An item list: > \begin{itemize} > \item abc def > \item [def] ghi > \item [jkl m n o] > \item pqr > \end{itemize} > The pdf output renders the second and third items incorrectly. If there > is no right bracket to terminate the argument, then pdf generation may > fail with message: > > org-latex-compile: PDF file ./example.pdf wasn't produced: Runaway argument This is (mis-)feature of LaTeX itemize and enumerate environments. The most simple way to "correct" output is to put '\relax' right after '\item' or output for these environments '\item[]' instead of solely '\item'. > I fixed these cases in my local environment using defadvise on org-latex-item > to wrap an initial left square bracket in braces. I used this form: > (eval-after-load "ox-latex" > '(progn > (defadvice org-latex-item (after escape-initial-bracket activate) > (setq ad-return-value > (replace-regexp-in-string > "\\\\item \\[" > "\\\\item {[}" > ad-return-value))))) > This changes the latex fragment for the above example to: > An item list: > \begin{itemize} > \item abc def > \item {[}def] ghi > \item {[}jkl m n o] > \item pqr > \end{itemize} > This form renders PDF correctly. My knowledge of latex is very limited, > I don't know if this is a reasonable approach or not. There appears to > be one other function in the ox-latex.el generating the \item command: > (org-latex-headline). I did not try to reproduce this case. [...] FWIW, itemize and enumerate environments are built on top of \list command, as well as 'description' environment. But only last environment uses 'optional' arguments for '\item', the first two shouldn't have such option. Unfortunately, there is only one '\item' command, that is used in all three environments. It is impossible to redefine "kernel" environments itemize and enumerate to work properly with '[]' after item, but some LaTeX packages could 'patch' standard environments to 'fix' the issue, for example, 'enumitem' package. --- WBR, Vladimir Lomov -- In an age when the fashion is to be in love with yourself, confessing to be in love with somebody else is an admission of unfaithfulness to one's beloved. -- Russell Baker
[-- Attachment #1: Type: text/plain, Size: 992 bytes --] Hello, Jon Degenhardt <jondegenhardt@yahoo.com> writes: > Export to Latex (org-latex-export-to-pdf) generates incorrect latex when > list items start with a left square bracket. This occurs because the > \item command interprets the left square bracket as the start of an > argument list. An example: > > An item list: > - abc def > - [def] ghi > - [jkl m n o] > - pqr > > This produces the latex fragment: > > An item list: > \begin{itemize} > \item abc def > \item [def] ghi > \item [jkl m n o] > \item pqr > \end{itemize} > > The pdf output renders the second and third items incorrectly. If there > is no right bracket to terminate the argument, then pdf generation may > fail with message: > > org-latex-compile: PDF file ./example.pdf wasn't produced: Runaway > argument Thank you for the report. Would the following patch solves the problem? Regards, -- Nicolas Goaziou [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-ox-latex-Fix-items-starting-with-a-square-bracket.patch --] [-- Type: text/x-diff, Size: 1757 bytes --] From 64a5290bd6b7b8d29e9b77ecc3fe7c29619e37e0 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou <n.goaziou@gmail.com> Date: Mon, 13 Jan 2014 17:48:19 +0100 Subject: [PATCH] ox-latex: Fix items starting with a square bracket * lisp/ox-latex.el (org-latex-headline, org-latex-item): Fix items starting with a square bracket Thanks to Jon Degenhardt for reporting it. --- lisp/ox-latex.el | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index 8294938..f695dfc 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -1374,7 +1374,12 @@ holding contextual information." (when (org-export-first-sibling-p headline info) (format "\\begin{%s}\n" (if numberedp 'enumerate 'itemize))) ;; Itemize headline - "\\item " full-text "\n" headline-label pre-blanks contents))) + "\\item " + (replace-regexp-in-string "\\`[ \t]*\\[" "{\\[}" full-text) + "\n" + headline-label + pre-blanks + contents))) ;; If headline is not the last sibling simply return ;; LOW-LEVEL-BODY. Otherwise, also close the list, before ;; any blank line. @@ -1565,7 +1570,12 @@ contextual information." (concat checkbox (org-export-data tag info))))))) (concat counter "\\item" (or tag (concat " " checkbox)) - (and contents (org-trim contents)) + (cond ((not contents) nil) + ((or tag + checkbox + (not (string-match "\\`[ \t]*\\[" contents))) + (org-trim contents)) + (t (replace-match "{[}" nil nil contents))) ;; If there are footnotes references in tag, be sure to ;; add their definition at the end of the item. This ;; workaround is necessary since "\footnote{}" command is -- 1.8.5.2
Hello, ** Nicolas Goaziou [2014-01-13 17:51:05 +0100]: > Hello, > Jon Degenhardt <jondegenhardt@yahoo.com> writes: >> Export to Latex (org-latex-export-to-pdf) generates incorrect latex when >> list items start with a left square bracket. This occurs because the >> \item command interprets the left square bracket as the start of an >> argument list. An example: >> An item list: >> - abc def >> - [def] ghi >> - [jkl m n o] >> - pqr >> This produces the latex fragment: >> An item list: >> \begin{itemize} >> \item abc def >> \item [def] ghi >> \item [jkl m n o] >> \item pqr >> \end{itemize} >> The pdf output renders the second and third items incorrectly. If there >> is no right bracket to terminate the argument, then pdf generation may >> fail with message: >> >> org-latex-compile: PDF file ./example.pdf wasn't produced: Runaway >> argument > Thank you for the report. Would the following patch solves the problem? I didn't test this patch, and could interpret it wrong, but, IMHO, when exporting lists to LaTeX into itemize or enumerate environments the most suitable approach would be to insert '\item's as \item{} or \item\relax Both prevents LaTeX engine to read next character and interpret it in some special way (simple \item read next character and if it is [], then it assumes that this is an optional argument to the command). > Regards, --- WBR, Vladimir Lomov -- I had the rare misfortune of being one of the first people to try and implement a PL/1 compiler. -- T. Cheatham
Hello and apologies for jumping uninvited into this thread. I very often make use of the [] feature in itemised lists to change individual bullet points, for instance. I would not like this feature to disappear: it would break many of my documents, especially my beamer presentations. In fact, I had started preparing an email to ask the check lists make use of this feature to make these lists look nicer when exported to LaTeX. For instance, if we have - [ ] not yet done - [X] this has been done the exporter currently generates \item $\square$ not yet done \item $\boxtimes$ this has been done I would like to have this instead which looks much nicer: \item [$\square$] not yet done \item [$\boxtimes$] this has been done Try it and see how much nicer the list looks... Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.1, Org release_8.2.4-322-gece429
Hello, Eric S Fraga <e.fraga@ucl.ac.uk> writes: > I very often make use of the [] feature in itemised lists to change > individual bullet points, for instance. I would not like this feature > to disappear: it would break many of my documents, especially my beamer > presentations. I sometimes use this feature, too. But, admittedly, it is a hack. I though about escaping first opening square bracket, but only if the item doesn't start with an export snippet. E.g, - [item --> \item\relax [item but, - @@latex:[\blacktriangle]@@ item --> \item [\blacktriangle] Unfortunately, I can't see how to not break your documents if we fix the problem. > In fact, I had started preparing an email to ask the check lists make > use of this feature to make these lists look nicer when exported to > LaTeX. For instance, if we have > > - [ ] not yet done > - [X] this has been done > > the exporter currently generates > > \item $\square$ not yet done > \item $\boxtimes$ this has been done > > I would like to have this instead which looks much nicer: > > \item [$\square$] not yet done > \item [$\boxtimes$] this has been done > > Try it and see how much nicer the list looks... This is orthogonal to the issue at hand. The problem is not the checkbox but what comes after. IOW, this feature can be implemented with or without fixing the bug above (also, a filter can do the job). Regards, -- Nicolas Goaziou
Nicolas Goaziou <n.goaziou@gmail.com> writes: [...] > I sometimes use this feature, too. But, admittedly, it is a hack. I guess it depends on the definition of /hack/... I think of it as a feature of lists in LaTeX. Whether this is view extends to org is of course open to debate. [...] > Unfortunately, I can't see how to not break your documents if we fix the > problem. If this is considered a problem, and you intend to fix it, then there is no way to avoid causing me difficulties. Although I would obviously prefer to keep the status quo, as I find this "feature" convenient, please don't let the inconvenience to me stop you fixing this. It won't take me that long to fix. >> In fact, I had started preparing an email to ask the check lists make >> use of this feature to make these lists look nicer when exported to >> LaTeX. For instance, if we have [...] > This is orthogonal to the issue at hand. It is indeed. Apologies for conflating the two. > The problem is not the checkbox but what comes after. I am not sure what you mean here? > IOW, this feature can be implemented with or > without fixing the bug above (also, a filter can do the job). Yes, I appreciate this. A filter is likely what I will end up using. Today I simply edited the LaTeX as I needed to get a document of actions etc. out to a bunch of people quickly. Thanks for your quick response and please do change the handling of []s if you think it would be for the org community's benefit. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2.5d-479-g8694aa
Eric S Fraga <e.fraga@ucl.ac.uk> writes: > I guess it depends on the definition of /hack/... I think of it as a > feature of lists in LaTeX. Whether this is view extends to org is of > course open to debate. I was only talking about Org. The problem there is that a square bracket at the beginning of an item can prevent you from exporting the document, which is clearly a bug. >> Unfortunately, I can't see how to not break your documents if we fix the >> problem. > > If this is considered a problem, and you intend to fix it, then there is > no way to avoid causing me difficulties. I'd like to fix it, yes. It will not help you with older documents, but what do you think about the export snippet exception I suggested? > Although I would obviously prefer to keep the status quo, as I find > this "feature" convenient, please don't let the inconvenience to me > stop you fixing this. It won't take me that long to fix. I'm open to alternative solutions. Though, I'd like to have a solution pushed to maint before Emacs release. >> The problem is not the checkbox but what comes after. > > I am not sure what you mean here? Not much. We want to take action when item's contents start with a square bracket. But that will not happen if that item already has a checkbox (in this case, contents first character doesn't mean much). Regards, -- Nicolas Goaziou
Nicolas Goaziou <n.goaziou@gmail.com> writes:
[...]
> I'd like to fix it, yes. It will not help you with older documents, but
> what do you think about the export snippet exception I suggested?
Sorry, I didn't get back to you on this. Although obviously more
cumbersome than my current approach, your suggestion would cover my main
use case *and* from org's point of view would be much more "honest". I
would be happy with this.
thanks,
eric
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.1, Org release_8.2.4-322-gece429
[-- Attachment #1: Type: text/plain, Size: 560 bytes --] Hello, Eric S Fraga <e.fraga@ucl.ac.uk> writes: > Nicolas Goaziou <n.goaziou@gmail.com> writes: > >> I'd like to fix it, yes. It will not help you with older documents, but >> what do you think about the export snippet exception I suggested? > > Sorry, I didn't get back to you on this. Although obviously more > cumbersome than my current approach, your suggestion would cover my main > use case *and* from org's point of view would be much more "honest". I > would be happy with this. So, here comes another patch. WDYT? Regards, -- Nicolas Goaziou [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-ox-latex-Fix-items-starting-with-a-square-bracket.patch --] [-- Type: text/x-diff, Size: 2362 bytes --] From fd99c294e2f5ae75fa5f6a23c1958bd437310d0c Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou <n.goaziou@gmail.com> Date: Mon, 13 Jan 2014 17:48:19 +0100 Subject: [PATCH] ox-latex: Fix items starting with a square bracket * lisp/ox-latex.el (org-latex-headline, org-latex-item): Fix items starting with a square bracket. Thanks to Jon Degenhardt, Vladimir Lomov and Eric S Fraga for contributing to the discussion. --- lisp/ox-latex.el | 28 ++++++++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index 8294938..8842923 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -1374,7 +1374,13 @@ holding contextual information." (when (org-export-first-sibling-p headline info) (format "\\begin{%s}\n" (if numberedp 'enumerate 'itemize))) ;; Itemize headline - "\\item " full-text "\n" headline-label pre-blanks contents))) + "\\item" + (and full-text (org-string-match-p "\\`[ \t]*\\[" full-text) + "\\relax") + " " full-text "\n" + headline-label + pre-blanks + contents))) ;; If headline is not the last sibling simply return ;; LOW-LEVEL-BODY. Otherwise, also close the list, before ;; any blank line. @@ -1564,7 +1570,25 @@ contextual information." (and tag (format "[{%s}] " (concat checkbox (org-export-data tag info))))))) - (concat counter "\\item" (or tag (concat " " checkbox)) + (concat counter + "\\item" + (cond + (tag) + (checkbox (concat " " checkbox)) + ;; Without a tag or a check-box, if CONTENTS starts with + ;; an opening square bracket, add "\relax" to "\item", + ;; unless the brackets comes from an initial export + ;; snippet (i.e. it is inserted willingly by the user). + ((and contents + (org-string-match-p "\\`[ \t]*\\[" contents) + (not (let ((e (car (org-element-contents item)))) + (and (eq (org-element-type e) 'paragraph) + (let ((o (car (org-element-contents e)))) + (and (eq (org-element-type o) 'export-snippet) + (eq (org-export-snippet-backend o) + 'latex))))))) + "\\relax ") + (t " ")) (and contents (org-trim contents)) ;; If there are footnotes references in tag, be sure to ;; add their definition at the end of the item. This -- 1.8.5.2
Nicolas Goaziou <n.goaziou@gmail.com> writes:
[...]
> So, here comes another patch. WDYT?
Seems to work fine. I've tried using the export snippets together with
the filter for checkboxes and my lists come out looking as they
should. Changing my documents won't be too onerous.
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2.5d-479-g8694aa.dirty
Hello Eric,
Eric S Fraga wrote:
> Seems to work fine. I've tried using the export snippets together with
> the filter for checkboxes and my lists come out looking as they
> should. Changing my documents won't be too onerous.
Would you mind sharing your filter (or put it on Worg hacks, maybe)?
Best regards,
Seb
--
Sebastien Vauban
Hello, Eric S Fraga <e.fraga@ucl.ac.uk> writes: > Nicolas Goaziou <n.goaziou@gmail.com> writes: > > [...] > >> So, here comes another patch. WDYT? > > Seems to work fine. Applied. Thank you. > I've tried using the export snippets together with the filter for > checkboxes and my lists come out looking as they should. Changing my > documents won't be too onerous. Good news, then. Regards, -- Nicolas Goaziou
Sebastien Vauban <sva-news@mygooglest.com> writes:
> Hello Eric,
>
> Eric S Fraga wrote:
>> Seems to work fine. I've tried using the export snippets together with
>> the filter for checkboxes and my lists come out looking as they
>> should. Changing my documents won't be too onerous.
>
> Would you mind sharing your filter (or put it on Worg hacks, maybe)?
Sure:
#+begin_src emacs-lisp
(defun esf/filter-checkbox-list-items (line backend channel)
(if (eq backend 'latex)
(replace-regexp-in-string "\\\\item \\$\\\\\\(square\\|boxtimes\\)\\$" "\\\\item [$\\\\\\1$]" line)))
(add-to-list 'org-export-filter-plain-list-functions 'esf/filter-checkbox-list-items)
#+end_src
It took a while to suss out the number of backslashes... :)
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2.5d-479-g8694aa.dirty
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> Sebastien Vauban <sva-news@mygooglest.com> writes:
>
>> Hello Eric,
>>
>> Eric S Fraga wrote:
>>> Seems to work fine. I've tried using the export snippets together with
>>> the filter for checkboxes and my lists come out looking as they
>>> should. Changing my documents won't be too onerous.
>>
>> Would you mind sharing your filter (or put it on Worg hacks, maybe)?
>
> Sure:
>
> #+begin_src emacs-lisp
> (defun esf/filter-checkbox-list-items (line backend channel)
> (if (eq backend 'latex)
> (replace-regexp-in-string "\\\\item \\$\\\\\\(square\\|boxtimes\\)\\$" "\\\\item [$\\\\\\1$]" line)))
>
> (add-to-list 'org-export-filter-plain-list-functions 'esf/filter-checkbox-list-items)
> #+end_src
>
> It took a while to suss out the number of backslashes... :)
The question is still open, though: should it be the default?
Regards,
--
Nicolas Goaziou
Nicolas Goaziou wrote: > Eric S Fraga <e.fraga-hclig2XLE9Zaa/9Udqfwiw@public.gmane.org> writes: >> Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> writes: >>> Eric S Fraga wrote: >>>> Seems to work fine. I've tried using the export snippets together with >>>> the filter for checkboxes and my lists come out looking as they >>>> should. Changing my documents won't be too onerous. >>> >>> Would you mind sharing your filter (or put it on Worg hacks, maybe)? >> >> Sure: >> >> #+begin_src emacs-lisp >> (defun esf/filter-checkbox-list-items (line backend channel) >> (if (eq backend 'latex) >> (replace-regexp-in-string "\\\\item \\$\\\\\\(square\\|boxtimes\\)\\$" "\\\\item [$\\\\\\1$]" line))) >> >> (add-to-list 'org-export-filter-plain-list-functions 'esf/filter-checkbox-list-items) >> #+end_src >> >> It took a while to suss out the number of backslashes... :) I can imagine ;-) > The question is still open, though: should it be the default? I'd vote for it, for both LaTeX and HTML. Best regards, Seb -- Sebastien Vauban
Sebastien Vauban <sva-news@mygooglest.com> writes: > Nicolas Goaziou wrote: [...] >> The question is still open, though: should it be the default? > > I'd vote for it, for both LaTeX and HTML. > > Best regards, > Seb As would I. Check boxes with bullet points look quite ugly. Removing the bullet point leaves a very clean format. I have no idea how to achieve this in HTML with filters, mind you... -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2.5d-479-g8694aa.dirty
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --] Hi all, Thanks much for quick attention and detail to this report. I don't know the surrounding details all that well, but this seems a very sound approach. It'll definitely help my own work, as the square brackets are a common technical notation, and it is useful to generate both html and pdf output from the same org mode files. --Jon ________________________________ From: Nicolas Goaziou <n.goaziou@gmail.com> To: Jon Degenhardt <jondegenhardt@yahoo.com> Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org> Sent: Thursday, January 16, 2014 6:54 AM Subject: Re: Bug: Export to Latex - Incorrect output for list items starting with left bracket [8.2.3c (8.2.3c-elpa @ /Users/jdegenhardt/.emacs.d/elpa/org-20131115/)] Hello, Eric S Fraga <e.fraga@ucl.ac.uk> writes: > Nicolas Goaziou <n.goaziou@gmail.com> writes: > > [...] > >> So, here comes another patch. WDYT? > > Seems to work fine. Applied. Thank you. > I've tried using the export snippets together with the filter for > checkboxes and my lists come out looking as they should. Changing my > documents won't be too onerous. Good news, then. Regards, -- Nicolas Goaziou [-- Attachment #2: Type: text/html, Size: 2182 bytes --]
Hello,
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> Sebastien Vauban <sva-news@mygooglest.com> writes:
>
>> Nicolas Goaziou wrote:
>
> [...]
>
>>> The question is still open, though: should it be the default?
>>
>> I'd vote for it, for both LaTeX and HTML.
>>
>> Best regards,
>> Seb
>
> As would I. Check boxes with bullet points look quite ugly. Removing
> the bullet point leaves a very clean format. I have no idea how to
> achieve this in HTML with filters, mind you...
I looked into implementing it in "ox-latex.el" (about time), but mixing
checkboxed ordered and unordered lists is not pretty then
- [-] A
1. [X] B
2. [-] C
- [ ] D
Regards,
--
Nicolas Goaziou