emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Eric S Fraga <ucecesf@ucl.ac.uk>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: org-mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: latex export and beamer columns
Date: Mon, 23 Nov 2009 22:15:53 +0000	[thread overview]
Message-ID: <87hbsklwfa.wl%ucecesf@ucl.ac.uk> (raw)
In-Reply-To: <B26BC3A0-A64D-4C7A-82C4-8CC817C47109@gmail.com>

At Mon, 23 Nov 2009 14:55:53 +0100, Carsten Dominik wrote:
> 
> Hi Eric,
> 
> I am now getting interested in beamer support.  I think this is
> interesting enough to implement special support for making beamer
> slides.

Excellent!

> Can I ask you to think about it in general terms, what would be useful
> to have?

I've been using org-mode for my presentations for a few months now and
intensively the past week or so for a set of lectures (70+ slides) I
have to give starting tomorrow (yikes!  had better get them
finished...!).  It's working remarkably well.

Beamer has many many features and I think it would violate the ethos
of org-mode if we attempted to support the majority of them.  Although
I can suggest a number of features I think would be nice to support,
I'm sure others will have a different subset they think is
critical... however, I will give it a go:

1. being able to easily specify columns.  I've proposed a solution
   works well for me but it is a bit clumsy and does impose a meaning
   on the 3rd and 4th level headings.  This might conflict with other
   potential uses for these headings obviously (cf. next point). Also,
   please see my response to your comment on the impact of this on
   normal latex export below.  The nice thing about using headings to
   indicate columns is the ease with which the columns can be
   re-ordered.

2. it would be nice to support the block environment in beamer.  The
   obvious way would be to use 3rd level headings to indicate blocks.
   In my case, I use these less frequently than columns which is why I
   chose to use 3rd level headings to indicate columns.  However, a
   solution that catered for both would be great.

   one solution I am playing with, given that I often have blocks
   within columns, is to use the 5th level headings for block
   headings:

--8<---------------cut here---------------start------------->8---
   ("\\section{%s}" . "\\section*{%s}")
   ("\\begin{frame}\\frametitle{%s}" "\\end{frame}"
    "\\begin{frame}\\frametitle{%s}" "\\end{frame}")
   ("\\begin{columns} \% %s" "\\end{columns}"
    "\\begin{columns} \% %s" "\\end{columns}")
   ("\\begin{column}{%s\\textwidth}" "\\end{column}"
    "\\begin{column}{%s\\textwidth}" "\\end{column}")
   ("\\begin{block}{%s}" "\\end{block}"
    "\\begin{block}{%s}" "\\end{block}")
--8<---------------cut here---------------end--------------->8---

   For example, the following would generate a block within a full
   width column on the slide:

--8<---------------cut here---------------start------------->8---
*** Another slide
***** columns
******* 1.0
********* My proposition
	  - work better
	  - work faster
	  - have a life
--8<---------------cut here---------------end--------------->8---

   Although clumsy, it works!  (set H:5 of course)

3. support for animation, typically through the special <N> tags on
   items and blocks (and more generally on most latex environments),
   would be nice.  This can be used to selectively display different
   parts of a slide.  One way to implement this, at least for itemized
   lists, would be through a new bullet point syntax, as in:

   <1-> item to display from first virtual "slide" onwards
   <2-3> display on second and third views of the slide
   <-4> display up to 4th view
   
   which would translate to 

   \begin{itemize}
   \item<1-> item to display from first virtual "slide" onwards
   \item<2-3> display on second and third views of the slide
   \item<-4> display up to 4th view
   \end{itemize}

   I have no idea how hard it would be to incorporate this into the
   current list handling however... although I can imagine it could be
   quite difficult.

4. as already mentioned in another email, passing arguments to the
   frame environment would also be quite useful.  This could be done
   with an attribute type of framework as done for figures and
   tables.  I don't use many options to frame but I do find the need
   to use [shrink=20] or similar often (because my default font
   setting for beamer is "bigger" and so slides with more than a few
   bullet points or equations quickly overflow the slide).

5. finally, I use tikz a great deal in my presentations.  However,
   this is probably best handled by the normal embedded latex features
   already present.

Again, this list is based on the features I find I use in beamer and
others will have other requirements unfortunately.

> One of the problems with your most recent solution for the columns
> problem is that the document no longer exports really well to a normal
> LaTeX document - or is this no issue because beamer has its own way to
> produce handouts, so that the LaTeX export of a document intended for
> beamer is not so interesting?

Yes, beamer provides a very nice handout mode (option "handout" to the
beamer document class).

> But also in a broader sense:  What would be useful?  I think making
> slides in this way, through org, could be extremely fast and useful.

It is indeed fast and very useful.  It's made preparing my slides much
less painful and almost a pleasure, especially the ease with which I
can now change the order of my presentation etc!  But I should say
that, for pedagogical reasons, I purposely keep my slides quite
simple as much as possible.

I look forward to seeing what you come up with!  I'm happy to send you
examples of both beamer and org-mode->beamer that I have prepared for
seminars and teaching.  Let me know.

  reply	other threads:[~2009-11-23 22:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-21 12:49 latex export and beamer columns Eric S Fraga
2009-11-21 13:34 ` Carsten Dominik
2009-11-22 12:12   ` Eric S Fraga
2009-11-22 15:15     ` Eric S Fraga
2009-11-22 15:29       ` Matt Lundin
2009-11-22 19:31         ` Eric S Fraga
2009-11-23 13:55       ` Carsten Dominik
2009-11-23 22:15         ` Eric S Fraga [this message]
2009-11-24  0:02           ` Daniel Martins
2009-11-24  6:55           ` Carsten Dominik
2009-11-24  8:36             ` Eric S Fraga
2009-11-24  8:49             ` Eric S Fraga
2009-11-24  8:59               ` Carsten Dominik
2009-11-24 18:02                 ` Eric S Fraga
2009-11-25  6:28                   ` Carsten Dominik
2009-11-25  9:27                     ` Eric S Fraga
2009-11-25 18:03                     ` Eric S Fraga
2009-11-25 23:25                       ` Carsten Dominik
2009-11-26  8:16                         ` Eric S Fraga
2009-11-26  9:05                           ` Carsten Dominik
2009-11-26 10:33                             ` Eric S Fraga
2009-11-23 14:53     ` Sébastien Vauban
2009-11-21 16:33 ` Thomas S. Dye
2009-11-22 12:00   ` Eric S Fraga
2009-11-26  1:52 ` Łukasz Stelmach
2009-11-26 18:25   ` Eric S Fraga
2009-11-26 19:54     ` Darlan Cavalcante Moreira

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87hbsklwfa.wl%ucecesf@ucl.ac.uk \
    --to=ucecesf@ucl.ac.uk \
    --cc=carsten.dominik@gmail.com \
    --cc=e.fraga@ucl.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).