emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] [ANN] e-latex back-end: changes to attributes syntax


From: Nicolas Goaziou
Subject: Re: [O] [ANN] e-latex back-end: changes to attributes syntax
Date: Wed, 28 Nov 2012 13:58:09 +0100

Hello,

Suvayu Ali <address@hidden> writes:

> On Wed, Nov 21, 2012 at 05:35:48PM +0100, Nicolas Goaziou wrote:
>>     
>>     Plain lists accept two optional attributes: `:environment' and
>>     `:options'.  The first one allows to use a non-standard environment
>>     (i.e. "inparaenum").  The second one allows to specify optional
>>     arguments for that environment (square brackets are not mandatory).
>>     
>
> Are these available for org-e-beamer too?  I tried without success.  It
> would be a great addition (along with the options for images
> below).  :)
>
>>     Images accept `:float', `:placement' and `:options' as attributes.
>>     `:float' accepts a symbol among `wrap', `multicolumn', and
>>     `figure', which defines the float environment for the table (if
>>     unspecified, an image with a caption will be set in a "figure"
>>     environment).  `:placement' is a string that will be used as
>>     argument for the environment chosen.  `:options' is a string that
>>     will be used as the optional argument for "includegraphics" macro.
>> 

Since Beamer back-end doesn't redefine how images are handled, you can
use the same properties as above, within an attr_latex keyword.

About special environments for plain lists, I'm unsure if this is a good
idea. AFAIK many don't support overlay specifications so it would lead
to errors when one provides both a special environment and an overlay,
i.e.:

--8<---------------cut here---------------start------------->8---
#+attr_beamer: :environment inparaenum :overlay "+-"
- item 1
- item 2
--8<---------------cut here---------------end--------------->8---

Also, Beamer has its own way to render standard lists (through themes)
and it could cause problems with foreign packages.

On the other hand, I can still make it easy for an user to shoot himself
in the foot: code-wise, it is cheap. What do you think?


Regards,

-- 
Nicolas Goaziou



reply via email to

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