emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
To: re.ITWSQOTHJVN9M-geNee64TY+gS+FvcfC7Uqw@public.gmane.org
Cc: public-emacs-orgmode-mXXj517/zsQ-wOFGN7rlS/M9smdsby/KFg@public.gmane.org,
	Sebastien Vauban
	<public-wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw-wOFGN7rlS/M9smdsby/KFg@public.gmane.org>
Subject: Re: **: Re: [dev] About a beamer back-end
Date: Thu, 21 Jun 2012 23:14:58 +0200	[thread overview]
Message-ID: <80vcik8izx.fsf@somewhere.org> (raw)
In-Reply-To: <87obocodo7.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> (Nicolas Goaziou's message of "Thu, 21 Jun 2012 18:03:20 +0200")



Hi Nicolas,

> "Sebastien Vauban" writes:
>
>>> - Sectioning and packages are extracted from `org-e-latex-classes'.
>>>   Since calling Beamer back-end is explicit, it can be applied on any
>>>   tex file, not only when that file starts with
>>>   "\documentclass{beamer}".  Additionally, an equivalent to
>>>   `org-beamer-use-parts' is unnecessary.
>>
>> I did not understand that one.
>
> At the moment, beamer exporter is hooked into regular latex exporter
> when latex class is "beamer".  This restriction is unnecessary when you
> consider beamer as an independent back-end (i.e. you can call beamer
> export even on your "article" setup).

Cool...

>> I'm wondering, though, how you support the special case of "beamer frame
>> level" set to 0, where we need to add the tag "B_frame" (in fact, the
>> property) to show where the frame really begins.
>
> Would you mind providing an example for that? I am not aware of that
> special case.

For sure, I'm willing to do so. Here an ECM of that feature:

--8<---------------cut here---------------start------------->8---
#+TITLE:     "Free" beamer frame level
#+OPTIONS:   H:3 num:t toc:t

#+startup: beamer
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [presentation,t]
#+BEAMER_HEADER_EXTRA: \usetheme{PaloAlto}\usecolortheme{default}
#+BEAMER_FRAME_LEVEL: 0

* Introduction

** Slide 1                                                           :B_frame:
   :PROPERTIES:
   :BEAMER_env: frame
   :END:

- =BEAMER_FRAME_LEVEL: 0= gives you some flexibility in deciding what is and
  isn't a frame.

- For example, this frame is directly located under the section
  "Introduction".

* Analysis

** Client

*** Slide 2                                                          :B_frame:
    :PROPERTIES:
    :BEAMER_env: frame
    :END:

- This frame is located under the section "Analysis", subsection "Client".

*** Slide 3                                                          :B_frame:
    :PROPERTIES:
    :BEAMER_env: frame
    :END:

- You explicitly have to say which headlines are a frame by setting the
  =BEAMER_env: frame= property.

** Supplier

*** Slide 4                                                          :B_frame:
    :PROPERTIES:
    :BEAMER_env: frame
    :END:

- This becomes visible through the =B_frame= tag (visual aid only).

* Conclusion

** Slide 5                                                           :B_frame:
   :PROPERTIES:
   :BEAMER_env: frame
   :END:

- This frame is directly located under the section "Conclusion".

- No need to create a (stupidly) redundant subsection called "Conclusion"...
--8<---------------cut here---------------end--------------->8---

>> I liked the fact we had 2 types of highlighting (bold, in black, and
>> alert, in red, in my case).
>>
>> I would say that, as Beamer has those 2 different highlightings, we should be
>> able to still support both. Is this a problem?
>
> Not really a problem, but Org limits text markup to six elements.  You
> can easily choose to use another one for bold (i.e. with filters),
> though.

Sorry to insist, but I don't think it's a good idea to suppress the
distinction between alert (generally mapped to @ in private Org
configurations) and bold (*).

If I follow your advice, to get back the bold, I would have to override
another symbol, like + for example.

Not mentioning the fact it won't be standard (if I ever distribute my Org
file), but I can't export my slides once to Beamer PDF, once to a standard
document PDF without seeing big differences in the interpretation of the
symbols.

While, on the contrary, if we have an apart symbol for alert (apart from bold,
as foreseen in Beamer), and if we include such a line for the standard PDF
export:

  \providecommand{\alert}[1]{\textbf{#1}}

or, better

  \providecommand{\alert}[1]{{\textcolor{red}{\bfseries{#1}}}}

we win on both sides (we can export to both Beamer and standard doc with both
bold and alert differentiated), don't we?

Best regards,
  Seb

-- 
Sebastien Vauban

  parent reply	other threads:[~2012-06-21 21:14 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-15 15:08 [dev] About a beamer back-end Nicolas Goaziou
2012-06-15 16:41 ` suvayu ali
2012-06-15 16:47   ` Avdi Grimm
2012-06-18  7:50     ` Eric S Fraga
2012-06-18 12:35       ` suvayu ali
2012-06-19 13:21       ` Nicolas Goaziou
2012-06-19 21:04         ` Eric S Fraga
2012-06-20  6:23           ` Greg Tucker-Kellogg
2012-06-20 11:55             ` Sebastien Vauban
2012-06-20 15:20               ` Eric S Fraga
2012-06-21 14:37           ` Nicolas Goaziou
2012-06-21 14:51             ` Sebastien Vauban
2012-06-21 16:03               ` Nicolas Goaziou
     [not found]                 ` <87obocodo7.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-06-21 21:14                   ` Sebastien Vauban [this message]
2012-06-25 22:39                     ` **: " Andreas Leha
2012-06-21 14:55             ` Rasmus
2012-06-21 15:56               ` Nicolas Goaziou
2012-06-21 16:36                 ` Rasmus
2012-06-21 16:49             ` suvayu ali
2012-06-22  7:54             ` Eric S Fraga
2012-06-18  6:32 ` Daniel Bausch
2012-06-18 10:17 ` Rasmus
2012-06-18 10:35   ` Sebastien Vauban
2012-06-18 12:00     ` Rasmus
2012-06-28 10:40 ` Andreas Leha
2012-06-28 10:47   ` suvayu ali
2012-06-28 10:50     ` Andreas Leha

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=80vcik8izx.fsf@somewhere.org \
    --to=wxhgmqzgwmuf-genee64ty+gs+fvcfc7uqw@public.gmane.org \
    --cc=public-emacs-orgmode-mXXj517/zsQ-wOFGN7rlS/M9smdsby/KFg@public.gmane.org \
    --cc=public-wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw-wOFGN7rlS/M9smdsby/KFg@public.gmane.org \
    --cc=re.ITWSQOTHJVN9M-geNee64TY+gS+FvcfC7Uqw@public.gmane.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).