emacs-orgmode
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] org-list-allow-alphabetical LaTeX export

From: Nick Dokos
Subject: Re: [O] org-list-allow-alphabetical LaTeX export
Date: Fri, 07 Jun 2013 01:01:18 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) 
Josiah Schwab <address@hidden> writes:

>> On 6 jun. 2013, at 10:20, Michael Bach <phaebz <at> gmail.com> wrote:
>>> The LaTeX exporter does not honor the setting of 
>>> org-list-allow-alphabetical.  
>
> A week or so ago I asked a similar question about the HTML export and lists.
> http://lists.gnu.org/archive/html/emacs-orgmode/2013-05/msg01324.html
> So I just wanted to toss in my 2ยข.
>
> On Jun 6, 2013, at 2:17 AM, Carsten Dominik wrote:
>> Conventions about the type of bullet to be used in a document belong
>> to the typesetting side, and I rather establish a global setting for
>> a document than follow my momentary decisions when I write the
>> Org-mode version of it.  On a similar vein, we do have lists
>> starting with - and * and +, but we still let LaTeX and HTML choose
>> what to use as a bullet.  To me this feels like the right behavior.
>
> I think this argument makes sense; and to be honest, that's probably
> how I want the exporter to behave most of the time.
>
> However, there is particular use case where I find this frustrating,
> which is writing problem sets.  There I like to reference other parts
> of the problems by name.  For example,
>
> a) Do something.
> b) Use your answer in part a) to do something else.
>
> Then, if I want to export it to multiple formats (say, html and pdf),
> there is no general way to tell orgmode: "my alphabetical bullet
> choice was meaningful, please try to preserve it".  One ends up
> inserting little workarounds for each export format.  Which is not a
> big deal, but when everything else works so seamlessly it's these
> little things that stand out :)
>

I don't have anything to add to what others have said on the
cross-reference question. But I did some investigation into
alpha lists and I wanted to expand a bit on that.

I looked at your earlier question and the latex question a bit and I
have a patch that implements something like what you want. However, I'm
not advocating that org actually implement this. In fact, there are good
reasons *not* to implement it (at least not in this form).

In the patch, there is a change in the parser so that it recognizes an
ordered-alpha list (in addition to the ordered, etc. lists it was
already recognizing). Then there are minor changes to ox-html.el:
basically ordered and ordered-alpha trigger the same response from the
exporter, except in one case: the opening of an ordered-alpha list
includes the ``type="a"'' thing. NB: the patch does not address any
of the other exporters.

However, the type="a" thingie in <ol> is a bad idea: it is deprecated in
the HTML spec, so it would be foolish to go chasing after it in
org. Here's what the spec says:

#+BEGIN_QUOTE

For the OL element, possible values for the type attribute are
summarized in the table below (they are case-sensitive):

Type    Numbering style
1       arabic numbers  1, 2, 3, ...
a       lower alpha     a, b, c, ...
A       upper alpha     A, B, C, ...
i       lower roman     i, ii, iii, ...
I       upper roman     I, II, III, ...

Note that the type attribute is deprecated and list styles should be
handled through style sheets.

For example, using CSS, one may specify that the style of numbers for
list elements in a numbered list should be lowercase roman numerals. In
the excerpt below, every OL element belonging to the class "withroman"
will have roman numerals in front of its list items.

<STYLE type="text/css">
OL.withroman { list-style-type: lower-roman }
</STYLE>
<BODY>
<OL class="withroman">
<LI> Step one ...  
<LI> Step two ...
</OL>
</BODY>

#+END_QUOTE

See http://www.w3.org/TR/html4/struct/lists.html#type-values.

Even if it were not deprecated, a good implementation would require org
to be able to generate all the values, which would probably require 
YAUO (yet another user option).

What org *could* do is to generate some discriminant (the "withroman" thing
above) so that the proper CSS could be applied.  Right now, there is no
such capability I believe. It could be done with YAUO, but I, for one,
think org has too many of those: we certainly don't need more unless it
is *really* necessary.

Here's the patch if you still want it: the only use for it
as far as I'm concerned is "educational":

Attachment: alpha-list.patch
Description: Alpha lists in the html exporter

So much for HTML.

For LaTeX, you can do alpha lists as follows (no patch needed):

--8<---------------cut here---------------start------------->8---
#+LATEX_HEADER: \usepackage{enumerate}

* Letters
#+ATTR_LATEX: :options [(a)]
a. foo
b. bar
c. baz


This is another list, and the option above does not apply to it - 
the enumerators are numbers by default:

a. foo
b. bar
c. baz

* Numbers
1. foo
2. bar
3. baz

This might look like a numbered list, but if you add an option
you can turn it into an alpha list:

#+ATTR_LATEX: :options [A]
1. foo
2. bar
3. baz
--8<---------------cut here---------------end--------------->8---

You can pass any of the options that the enumerate package allows
without org having to worry about it.

-- 
Nick
reply via email to
[Prev in Thread] Current Thread [Next in Thread]