Re: [O] New exporter, beamer confusion
On Mon, Feb 04, 2013 at 12:00:08PM +0800, James Harkins wrote: > #+OPTIONS: H:10 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t The H:10 is your problem. Since you want 2nd level headlines to be frames, it should be H:2. Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] New exporter, beamer confusion
Suvayu Ali gmail.com> writes: > On Mon, Feb 04, 2013 at 12:00:08PM +0800, James Harkins wrote: > > #+OPTIONS: H:10 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t > > The H:10 is your problem. Since you want 2nd level headlines to be > frames, it should be H:2. Ah. OK, that's an improvement. Still a problem, though. The old exporter preserves the outline structure under the frame level, as nested bullet lists. The new exporter flattens them. * In: * Section A ** Slide 1 *** Third-level Fourth-level * Old exporter: Slide 1 --- - Third-level -- Fourth-level * New exporter: Slide 1 --- Third-level Fourth-level Should the new exporter change the appearance of my presentations so much? I'm hoping there's an option for this (as redoing the markup for 20 or more sets of class slides is... painful to contemplate). Thanks, hjh
Re: [O] New exporter, beamer confusion
Hello, James Harkins writes: > Suvayu Ali gmail.com> writes: > >> On Mon, Feb 04, 2013 at 12:00:08PM +0800, James Harkins wrote: >> > #+OPTIONS: H:10 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t >> >> The H:10 is your problem. Since you want 2nd level headlines to be >> frames, it should be H:2. > > Ah. OK, that's an improvement. > > Still a problem, though. The old exporter preserves the outline structure > under > the frame level, as nested bullet lists. The new exporter flattens them. > > * In: > > * Section A > ** Slide 1 > *** Third-level > Fourth-level > > * Old exporter: > > Slide 1 > --- > - Third-level > -- Fourth-level > > * New exporter: > > Slide 1 > --- > Third-level > Fourth-level > > Should the new exporter change the appearance of my presentations so much? > I'm > hoping there's an option for this (as redoing the markup for 20 or more sets > of > class slides is... painful to contemplate). Here's an excerpt from ox-beamer.el documentation: ;; - Headlines become frames when their level is equal to ;; `org-beamer-frame-level' (or "H" value in the OPTIONS line). ;; Though, if an headline in the current tree has a "BEAMER_env" ;; (see below) property set to either "frame" or "fullframe", its ;; level overrides the variable. A "fullframe" is a frame with an ;; empty (ignored) title. ;; ;; - All frames' children become block environments. Special block ;; types can be enforced by setting headline's "BEAMER_env" property ;; to an appropriate value (see `org-beamer-environments-default' ;; for supported value and `org-beamer-environments-extra' for ;; adding more). In particular, "All frames children become block environments". So in your example Third-level is a block environment and Fourth-level is a block within it. There's no flattening going on (look at the tex file to convince yourself). Regards, -- Nicolas Goaziou
Re: [O] New exporter, beamer confusion
On Feb 5, 2013 3:51 AM, "Nicolas Goaziou" wrote: > In particular, "All frames children become block environments". So in > your example Third-level is a block environment and Fourth-level is > a block within it. There's no flattening going on (look at the tex file > to convince yourself). Thanks for pointing me to the comments in the .el source file. So here's my situation. I have a year's worth of lecture slides that render nicely using the old exporter. In the new exporter, the clear hierarchies of "enumerate" environments disappear, replaced by flat blocks. This new behavior is not useful to me. The comments in the source don't say anything about how I can modify the default "block" behavior. As a result, if the new exporter is fundamentally incompatible with the old and the only way is to insert properties by hand under every headline (across all of my files, I'd guess the count is in the high hundreds, if not >1000)... then the new beamer exporter is not useful to me. Is there an existing feature request for this? If not, would it help if I logged one? (Even if I didn't have existing files -- I like bullet points on slides, not flat text. I don't understand why I shouldn't be able to set that as a global or per-file preference.) I don't mean to be harsh. I'm glad for the new exporter and I'll use it for the next article I write. For beamer, though, currently it sounds like a lot of work to get a result that used to be easy. hjh
Re: [O] New exporter, beamer confusion
James Harkins wrote:
> On Feb 5, 2013 3:51 AM, "Nicolas Goaziou" wrote:
> > In particular, "All frames children become block environments". So in
> > your example Third-level is a block environment and Fourth-level is
> > a block within it. There's no flattening going on (look at the tex file
> > to convince yourself).
>
> Thanks for pointing me to the comments in the .el source file.
>
> So here's my situation. I have a year's worth of lecture slides that render
> nicely using the old
> exporter. In the new exporter, the clear hierarchies of "enumerate"
> environments disappear, replaced
> by flat blocks. This new behavior is not useful to me.
>
> The comments in the source don't say anything about how I can modify the
> default "block" behavior.
> As a result, if the new exporter is fundamentally incompatible with the old
> and the only way is to
> insert properties by hand under every headline (across all of my files, I'd
> guess the count is in
> the high hundreds, if not >1000)... then the new beamer exporter is not
> useful to me.
>
Customizing org-e-beamer-environments-extra should do the trick. I was
experimenting using the *scratch* buffer, so the following are temporary
settings, cribbed from those experiments: restart emacs and they
disappear.
Something like the following perhaps (very lightly tested - nb: I really
haven't played with the new exporter very much at all):
--8<---cut here---start->8---
(setq blockenv '("block" "b" "\\begin{itemize}\\item %h" "\\end{itemize}"))
(add-to-list 'org-e-beamer-environments-extra blockenv t)
--8<---cut here---end--->8---
I added a beamer entry to org-e-latex-classes as indicated in
http://thread.gmane.org/gmane.emacs.orgmode/61497/focus=61536
by just copying the article entry and modifying it slightly (again, I
have no idea if the sectioning stuff matters or not, and whether it leads
to problems - improvements/corrections would be welcome):
--8<---cut here---start->8---
(setq beamerclass '("beamer" "\\documentclass[11pt]{beamer}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
(add-to-list 'org-e-latex-classes beamerclass t)
--8<---cut here---end--->8---
That's enough to export your ECM I think - no guarantees for
anything more complicated.
Nick
> Is there an existing feature request for this? If not, would it help if I
> logged one? (Even if I
> didn't have existing files -- I like bullet points on slides, not flat text.
> I don't understand why
> I shouldn't be able to set that as a global or per-file preference.)
>
> I don't mean to be harsh. I'm glad for the new exporter and I'll use it for
> the next article I
> write. For beamer, though, currently it sounds like a lot of work to get a
> result that used to be
> easy.
>
> hjh
>
>
>
> Alternatives:
>
>
Re: [O] New exporter, beamer confusion
On Tue, Feb 5, 2013 at 3:21 PM, Nick Dokos wrote:
> I added a beamer entry to org-e-latex-classes as indicated in
>
> http://thread.gmane.org/gmane.emacs.orgmode/61497/focus=61536
>
> (again, I
> have no idea if the sectioning stuff matters or not, and whether it leads
> to problems - improvements/corrections would be welcome):
Made no difference for me.
> Customizing org-e-beamer-environments-extra should do the trick. I was
> experimenting using the *scratch* buffer, so the following are temporary
> settings, cribbed from those experiments: restart emacs and they
> disappear.
>
> Something like the following perhaps (very lightly tested - nb: I really
> haven't played with the new exporter very much at all):
>
> --8<---cut here---start->8---
> (setq blockenv '("block" "b" "\\begin{itemize}\\item %h" "\\end{itemize}"))
> (add-to-list 'org-e-beamer-environments-extra blockenv t)
> --8<---cut here---end--->8---
I'm attaching an org file that illustrates a couple of the beamer
formatting options that I used a lot in the old exporter.
1. I *did* use the block environment to emphasize some text by pulling
it out of the "itemize" bullet lists. If I customize blockenv in org
to render as "itemize," then I lose the ability to do this (or, I have
to call "block" something else).
2. BMCOL (column) layouts are completely ignored.
3. Strong *emphasis* now renders in red, instead of keeping the text's
original color and switching to boldface.
I've also uploaded 3 PDFs to UbuntuOne, the point being to illustrate
how much functionality is lost in the new exporter:
1. Old exporter result
http://ubuntuone.com/2ByUYyYg5wfz07aUuUVPTP
2. New exporter result, without customizing
http://ubuntuone.com/4HSQUoDlZpNHZ46OROZd54
3. New exporter result, with Nick's customization
http://ubuntuone.com/1DnRQultVtdf2OKYjaeSsu
I get the feeling here that the new beamer exporter was written
without a lot of real-world user requirements. Certainly, it's
understandable that HTML, LaTeX article-style and ODT exporters would
be more widely used and more important to get right first. For beamer,
though, I can't reconcile the announcement ("Even though the internals
are completely different, the new exporter mostly behaves like its
predecessor. There are only a few noticeable changes") with the fact
that the new beamer exporter is a rather different animal that
completely breaks compatibility with org files written for the old
exporter, and may actually require a complete redo of the org markup
for each file.
I know my emacs-lisp chops are not up to the task of fixing what is
broken in the new beamer exporter. I can supply a couple dozen source
files, to help decide what level of backward compatibility is
feasible. I'm not sure how else I can help.
At least, it would be good to clarify, with respect to the
announcement, if the new beamer exporter is intended to be reasonably
backward-compatible with the old (with not-too-intrusive tweaks). If
that was the intent, then it's not ready for release. Otherwise, I'd
be happy to help draw up an upgrade path for people like myself who
have developed workflows for the old exporter that will eventually not
be supported anymore.
In the meantime, I must stick with the old exporter, though I'll keep
the discussion alive to hash out on the mailing list what needs to be
done to make the new one production-ready for me.
hjh
simple-beamer.org
Description: Binary data
Re: [O] New exporter, beamer confusion
Nick Dokos writes: [...] > Customizing org-e-beamer-environments-extra should do the trick. I was Nick, thanks for this. This hint led me to org-e-beamer-select-environment which, after binding to a key, has allowed me to play sufficiently enough with the new exporter and beamer that I am now less worried about the upcoming change in default behaviour! eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-898-gcb1386
Re: [O] New exporter, beamer confusion
Nicolas Goaziou writes: [...] > Here's an excerpt from ox-beamer.el documentation: > > ;; - Headlines become frames when their level is equal to > ;; `org-beamer-frame-level' (or "H" value in the OPTIONS line). Nicolas, I have decided to bite the bullet and try to get all of my beamer files working with the new exporter. I have started simply with the presentation.org file that I had put on Worg for the tutorial on beamer for the old exporter. A truncated version of that file (very minimal and attached) fails completely to export. I get the following (truncated) error trace: , | Debugger entered--Lisp error: (wrong-type-argument buffer-or-string-p t) | get-text-property(0 org-props t) | org-get-text-property-any(0 org-props t) | org-beamer-sectioning(1 t) | funcall(org-beamer-sectioning 1 t) | (if (and (symbolp (nth 2 class-sectionning)) (fboundp (nth 2 class-sectionning))) (funcall (nth 2 class-sectionning) level numberedp) (nth (1+ level) class-sectionning)) | ... | org-e-latex-headline((headline (:raw-value "Introduction" :begin 359 :end 444 ... ` I have attached the simple test file. Where am I going wrong? If I change H:2 to H:1, it works although obviously the output is not what I want. Have I misunderstand something rather fundamental? Thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-898-gcb1386 #+TITLE: Writing Beamer presentations in org-mode #+AUTHOR:Eric S Fraga #+EMAIL: e.fr...@ucl.ac.uk #+DATE: 2010-03-30 Tue #+startup: oddeven #+LaTeX_CLASS: beamer #+LaTeX_CLASS_OPTIONS: [bigger] #+BEAMER_THEME: Madrid #+OPTIONS: H:2 # +COLUMNS: %20ITEM %13BEAMER_env(Env) %6BEAMER_envargs(Args) %4BEAMER_col(Col) %7BEAMER_extra(Extra) * Introduction ** Overview - org-mode template - beamer structure - beamer settings
Re: [O] New exporter, beamer confusion
Hi James, James Harkins wrote: > 3. Strong *emphasis* now renders in red, instead of keeping the text's > original color and switching to boldface. That's because the * are exported as \alert macros in the new exporter (instead of \textbf in the old one -- for bold face). As, in the LaTeX's Beamer back-end, you have the ability to either use alert or bold face, I'd be very happy to do the same from the source Org file, using: - `*' for bold (as always), - `@' for alert (for example[1]). Though, this is not currently implemented this way, and the default has been changed between the old and the new exporters. IIRC, Nicolas' answer was to insert \textbf calls where you want such use of bold face. Or maybe overwriting one variable which would be the macro used for translation `*' characters -- but, then, you must anyway use one LaTeX macro or the other. Best regards, Seb [1] I think this is Eric Fraga's initial choice of meta-character for alert in the old exporter (using extra custom code). -- Sebastien Vauban
Re: [O] New exporter, beamer confusion
James Harkins wrote:
> ...
>
> I get the feeling here that the new beamer exporter was written
> without a lot of real-world user requirements. Certainly, it's
> understandable that HTML, LaTeX article-style and ODT exporters would
> be more widely used and more important to get right first. For beamer,
> though, I can't reconcile the announcement ("Even though the internals
> are completely different, the new exporter mostly behaves like its
> predecessor. There are only a few noticeable changes") with the fact
> that the new beamer exporter is a rather different animal that
> completely breaks compatibility with org files written for the old
> exporter, and may actually require a complete redo of the org markup
> for each file.
>
> I know my emacs-lisp chops are not up to the task of fixing what is
> broken in the new beamer exporter. I can supply a couple dozen source
> files, to help decide what level of backward compatibility is
> feasible. I'm not sure how else I can help.
>
> At least, it would be good to clarify, with respect to the
> announcement, if the new beamer exporter is intended to be reasonably
> backward-compatible with the old (with not-too-intrusive tweaks). If
> that was the intent, then it's not ready for release. Otherwise, I'd
> be happy to help draw up an upgrade path for people like myself who
> have developed workflows for the old exporter that will eventually not
> be supported anymore.
>
> In the meantime, I must stick with the old exporter, though I'll keep
> the discussion alive to hash out on the mailing list what needs to be
> done to make the new one production-ready for me.
>
I'm sure Nicolas is up to his ears in prep work, but eventually I'm sure
he or somebody else who knows more about it than I do, will comment.
Just as a general precaution, I wouldn't rush to judgement based on
my fumbling attempts: these were small experiments done without knowing
anything about the new exporter to begin with. I hope that they did more
good than harm, but it *is* just a hope on my part. Don't mistake them
for authoritative information.
Nick
Re: [O] New exporter, beamer confusion
Hello, Eric S Fraga writes: > I have decided to bite the bullet and try to get all of my beamer files > working with the new exporter. I have started simply with the > presentation.org file that I had put on Worg for the tutorial on beamer > for the old exporter. > > A truncated version of that file (very minimal and attached) fails > completely to export. I get the following (truncated) error trace: > > , > | Debugger entered--Lisp error: (wrong-type-argument buffer-or-string-p t) > | get-text-property(0 org-props t) > | org-get-text-property-any(0 org-props t) > | org-beamer-sectioning(1 t) > | funcall(org-beamer-sectioning 1 t) > | (if (and (symbolp (nth 2 class-sectionning)) (fboundp (nth 2 > class-sectionning))) (funcall (nth 2 class-sectionning) level numberedp) (nth > (1+ level) class-sectionning)) > | ... > | org-e-latex-headline((headline (:raw-value "Introduction" :begin 359 :end > 444 ... > ` > > I have attached the simple test file. > > Where am I going wrong? If I change H:2 to H:1, it works although > obviously the output is not what I want. Have I misunderstand something > rather fundamental? I have no problem exporting this file. Though, judging from the backtrace, you're using the old exporter since `org-beamer-sectioning' comes from it. Regards, -- Nicolas Goaziou
Re: [O] New exporter, beamer confusion
Hello,
> I'm attaching an org file that illustrates a couple of the beamer
> formatting options that I used a lot in the old exporter.
See below.
> 1. I *did* use the block environment to emphasize some text by pulling
> it out of the "itemize" bullet lists. If I customize blockenv in org
> to render as "itemize," then I lose the ability to do this (or, I have
> to call "block" something else).
>
> 2. BMCOL (column) layouts are completely ignored.
No. BMCOL are just different.
> 3. Strong *emphasis* now renders in red, instead of keeping the text's
> original color and switching to boldface.
Indeed. Strong emphasis in Beamer's jargon is \alert{...} (see Beamer
documentation about it). Letter are so large that \textbf{...} doesn't
fill the job well enough. I'm not saying that \textbf{...} is useless
(though I think it), but "alert" was preferred.
> I get the feeling here that the new beamer exporter was written
> without a lot of real-world user requirements.
FWIW, I have used it almost daily since I wrote it.
> Certainly, it's understandable that HTML, LaTeX article-style and ODT
> exporters would be more widely used and more important to get right
> first. For beamer, though, I can't reconcile the announcement ("Even
> though the internals are completely different, the new exporter mostly
> behaves like its predecessor. There are only a few noticeable
> changes") with the fact that the new beamer exporter is a rather
> different animal that completely breaks compatibility with org files
> written for the old exporter, and may actually require a complete redo
> of the org markup for each file.
You are half correct. I admit: I forgot to mention that Beamer back-end
was a bit different from its predecessor. Though, it doesn't require
a complete redo, there's just some work to do at the headline level.
> I know my emacs-lisp chops are not up to the task of fixing what is
> broken in the new beamer exporter.
Nothing is broken in it (at least AFAIK). There are just some changes to
do.
> I can supply a couple dozen source
> files, to help decide what level of backward compatibility is
> feasible. I'm not sure how else I can help.
Let's start slowly. I think you can get how to make the changes yourself
with a couple of examples. Since you seem to like lists (you know that
Till Tantau frowns upon the use of third level lists in presentations,
don't you?), the first rule to know is:
Headlines will never, ever, become lists in the new Beamer back-end.
If you want lists, use lists. There's a handy command to do that change:
mark the subtree you want to change, and use "C-c -".
New back-end is more block friendly than lists friendly.
> At least, it would be good to clarify, with respect to the
> announcement, if the new beamer exporter is intended to be reasonably
> backward-compatible with the old (with not-too-intrusive tweaks).
It all depends on what you mean by reasonably. You can obtain the same
output, but there are changes to make in Org files.
> If that was the intent, then it's not ready for release. Otherwise,
> I'd be happy to help draw up an upgrade path for people like myself
> who have developed workflows for the old exporter that will eventually
> not be supported anymore.
Thank you. I'll try to help you get started. You might even come to like
the new back-end in the process.
> In the meantime, I must stick with the old exporter, though I'll keep
> the discussion alive to hash out on the mailing list what needs to be
> done to make the new one production-ready for me.
Fair enough.
I'm attaching an updated version of your simple document. Besides moving
subtree to lists, there only other change was at the columns level.
If you use a headline with only a BEAMER_col property, its title will be
ignored and can be used as a container. If you provide it an additional
environment (like block), the new environment will be put in the column
and will fill it. Moreove, the :BEAMER_col: property requires a decimal
number as value, not a length.
Oh, yes, and BEAMER_FRAME_LEVEL doesn't exist anymore. It's H:... in the
OPTIONS line.
#+begin_src org
#+LANGUAGE: en
#+OPTIONS: H:2 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc
#+startup: beamer
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [presentation]
#+BEAMER_THEME: default
#+COLUMNS: %45ITEM %10BEAMER_env(Env) %10BEAMER_act(Act) %4BEAMER_col(Col)
%8BEAMER_opt(Opt)
#+PROPERTY: BEAMER_col_ALL 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.0 :ETC
#+TITLE: Testing new beamer exporter
#+AUTHOR:H. James Harkins
#+EMAIL: jamshar...@yaddayadda.com
#+DATE: 7 November 2012
#+BEGIN_LaTeX
\AtBeginSection[] % Do nothing for \section*
{
\begin{frame}
\frametitle{Outline}
\tableofcontents[currentsection]
\end{frame}
}
#+END_LaTeX
* Section A
** Slide 1
- Third-level
- Fourth-level
** Ancient history: *Music \emph{n}* languages
- Early pioneers at *B
Re: [O] New exporter, beamer confusion
Nicolas Goaziou writes:
[...]
>> I have attached the simple test file.
>>
>> Where am I going wrong? If I change H:2 to H:1, it works although
>> obviously the output is not what I want. Have I misunderstand something
>> rather fundamental?
>
> I have no problem exporting this file. Though, judging from the
> backtrace, you're using the old exporter since `org-beamer-sectioning'
> comes from it.
Which is rather strange although that thought had entered my mind. I do
not understand how I am ending up in that code when I start the exporter
off with the new dispatcher. Other files work fine but this one
doesn't.
The funny thing is that if I use the old dispatcher, and hence the old
exporter, it works!
There has to be something in my emacs/org configuration somewhere that
is causing problems.
So I try a minimal example (emacs -Q, set up paths to git org, load in
org-e-beamer) and things get even stranger. The same org file exports
(no error), but to a latex file that has no document class
definition. The first (non-comment) line of the latex file is
\usetheme{Madrid}.
I am really confused. The system is rather fragile, it would seem.
I will continue playing... although I guess I should try to do some
work as well ;-)
--
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-897-g787a07
Re: [O] New exporter, beamer confusion
Nicolas Goaziou writes: [...] > Let's start slowly. I think you can get how to make the changes yourself > with a couple of examples. Since you seem to like lists (you know that > Till Tantau frowns upon the use of third level lists in presentations, > don't you?), the first rule to know is: [...] Nicolas, this email has been quite helpful. I now see where you have gone with beamer and overall I like your approach. However, I *still* cannot get this to work. Taking your updated version of the example document, I cannot get the exporter to generate a latex file that will compile because it is missing a documentclass directive. Is there something else that needs to be configured to support beamer, as in maybe org-e-latex-classes? The default has no mention of beamer and although the documentation within org-e-beamer.el does allude to org-e-latex-classes, it doesn't say whether that variable needs to be adapted/updated/changed. Having looked at the code, I think I do need to add a "beamer" entry to that variable. Can you please suggest a default that would work? And maybe update the documentation or at least output an error message if the latex class desired is not actually found in org-e-beamer-template? That function would appear to do nothing if an appropriate entry is not found and hence explains why I get an exported file with no documentclass line! Thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-897-g787a07
Re: [O] New exporter, beamer confusion
Thanks for all this. I'll look at the new org markup later today. That
should help a lot.
On Feb 6, 2013 3:03 AM, "Nicolas Goaziou" wrote:
> > 3. Strong *emphasis* now renders in red, instead of keeping the text's
> > original color and switching to boldface.
>
> Indeed. Strong emphasis in Beamer's jargon is \alert{...} (see Beamer
> documentation about it). Letter are so large that \textbf{...} doesn't
> fill the job well enough. I'm not saying that \textbf{...} is useless
> (though I think it), but "alert" was preferred.
Ok. There was something about customizing this on the list just recently.
I'll use that. (FWIW, I had to produce a number of *gasp cough choke*
PowerPoint shows in my previous job, and they told us not to use red for
*anything* unless it really was a four-alarm-fire "you will really screw
things up if you ignore this" type of point, and I retain this aversion to
red text to this day.)
Btw, *who* preferred \alert? (Orwell, Politics and the English Language:
"Never use the passive [voice] where you can use the active.")
> Since you seem to like lists (you know that
> Till Tantau frowns upon the use of third level lists in presentations,
> don't you?)
I appreciate his contribution to LaTeX, but I'll make my own decisions
about style, thanks.
> Headlines will never, ever, become lists in the new Beamer back-end.
>
> If you want lists, use lists. There's a handy command to do that change:
> mark the subtree you want to change, and use "C-c -".
>
> New back-end is more block friendly than lists friendly.
Although I'm not happy about manual intervention to convert my prior work,
this is a good step toward consistency. It was odd, in the old framework,
to use headlines for bullet lists and org's numbered lists for numbered
lists. "An org list becomes an output list" is an easier rule to explain.
Still, I wonder if there is a way to make the new backend less unfriendly
toward lists. It's an interesting philosophical question: In what cases is
it better for the tool to adapt to the users' wishes, versus cases where
the tool should encourage (Are blocks in the result actually better than
lists? Who says so, and why should I take his or her word for it?)
> > At least, it would be good to clarify, with respect to the
> > announcement, if the new beamer exporter is intended to be reasonably
> > backward-compatible with the old (with not-too-intrusive tweaks).
>
> It all depends on what you mean by reasonably. You can obtain the same
> output, but there are changes to make in Org files.
"Reasonably" for me would mean tweaking some configuration options and
perhaps changing a few minor details of the markup. If you have to change
the org document's structure (e.g., converting headlines to lists), it
isn't backward compatible.
For comparison: Lilypond updates frequently break some details of backward
compatibility. So, they ship a "convert-ly" script to handle many of those
changes automatically.
> Oh, yes, and BEAMER_FRAME_LEVEL doesn't exist anymore. It's H:... in the
> OPTIONS line.
Right, covered in an earlier message in this thread. I included it here so
you could compile it using the old exporter, for comparison.
> I'm attaching an updated version of your simple document. Besides moving
> subtree to lists, there only other change was at the columns level.
Thanks for this, and the explanation of columns. Actually, I never was
really happy with columns in the old backend. It's quite likely to be
better here!
Really appreciate the details.
hjh
Re: [O] New exporter, beamer confusion
James Harkins writes:
[...]
> Ok. There was something about customizing this on the list just recently.
> I'll use that. (FWIW, I had to produce a number of *gasp cough choke*
> PowerPoint shows in my previous job, and they told us not to use red for
> *anything* unless it really was a four-alarm-fire "you will really screw
> things up if you ignore this" type of point, and I retain this aversion to
> red text to this day.)
#+BEAMER: \setbeamercolor{alerted text}{...some other colour...}
--
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-897-g787a07
Re: [O] New exporter, beamer confusion
James Harkins writes:
> Btw, *who* preferred \alert? (Orwell, Politics and the English Language:
> "Never use the passive [voice] where you can use the active.")
I prefer alert. See the Beamer manual (texdoc beamer in texlive) on
change of style and how to use alert (e.g. alert on one particular
(sub)slide of a "multipage slide"). It's the Beamer way. Surely it
cannot be a bad thing?
> Still, I wonder if there is a way to make the new backend less unfriendly
> toward lists. It's an interesting philosophical question: In what cases is
> it better for the tool to adapt to the users' wishes, versus cases where
> the tool should encourage (Are blocks in the result actually better than
> lists? Who says so, and why should I take his or her word for it?)
Org has many dedicated list symbols namely white space and one of
{[-+*], [0-9][.)]}. Why should a headline be converted to a list? It
was always awkward to me.
I don't know how hard it would be to make the "default" block (of
level 3, say) a list block, but I guess that's ultimately what you
want? Such a behavior shouldn't be the default, IMO, since a headline
is not a list.
> "Reasonably" for me would mean tweaking some configuration options and
> perhaps changing a few minor details of the markup. If you have to change
> the org document's structure (e.g., converting headlines to lists), it
> isn't backward compatible.
I'm sure it would be relatively quick to hack together a couple of
regexps and some lisp to do the conversion if you prefer to use the
new exporter. E.g. find every occurrence of * in the beginning of the
line of length X and convert each occurrence to "-" with appropriate
white space (e.g. X + N).
What might be useful would be a tag telling Org to use the legacy
exporter on a file basis, although it would also be a short run
solution.
–Rasmus
--
Summon the Mothership!
Re: [O] New exporter, beamer confusion
On Wed, Feb 06, 2013 at 01:32:22PM +0100, Rasmus wrote: > > I don't know how hard it would be to make the "default" block (of > level 3, say) a list block, but I guess that's ultimately what you > want? Such a behavior shouldn't be the default, IMO, since a headline > is not a list. > Nested headlines being translated to lists was always a misfeature in the old exporter. This was extensibly discussed on the list before Nicolas implemented the current beamer exporter. I do not see any reason to not "fix" old inconsistent behaviour for the sake of backwards compatibility. That said, I think the best way to deal with this is to follow what Nicolas suggested, mark the subtree and then do `C-c -' to convert these headlines into lists. This can be automated to a significant degree by using keyboard macros or custom lisp. A well tested keyboard macro can be easily saved and used as a command. Since the OP says his old beamer presentations number in the hundreds, the way I would approach this is to keep the macro/function handy and convert it if and when these presentations are required. Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] New exporter, beamer confusion
Hi Rasmus,
Rasmus wrote:
> James Harkins writes:
>
>> Btw, *who* preferred \alert? (Orwell, Politics and the English Language:
>> "Never use the passive [voice] where you can use the active.")
>
> I prefer alert. See the Beamer manual (texdoc beamer in texlive) on
> change of style and how to use alert (e.g. alert on one particular
> (sub)slide of a "multipage slide"). It's the Beamer way. Surely it
> cannot be a bad thing?
>
>> Still, I wonder if there is a way to make the new backend less unfriendly
>> toward lists. It's an interesting philosophical question: In what cases is
>> it better for the tool to adapt to the users' wishes, versus cases where
>> the tool should encourage (Are blocks in the result actually better than
>> lists? Who says so, and why should I take his or her word for it?)
>
> Org has many dedicated list symbols namely white space and one of
> {[-+*], [0-9][.)]}. Why should a headline be converted to a list? It
> was always awkward to me.
As a reminder, the conversion of headlines to lists is what "daily" happens
within common Org files converted to LaTeX documents: just play with the H
option, and you'll see your deeper levels converted to LaTeX lists.
So, this ain't specific to Beamer.
Best regards,
Seb
--
Sebastien Vauban
Re: [O] New exporter, beamer confusion
Hello,
Eric S Fraga writes:
> Taking your updated version of the example document, I cannot get the
> exporter to generate a latex file that will compile because it is
> missing a documentclass directive. Is there something else that needs
> to be configured to support beamer, as in maybe org-e-latex-classes?
Indeed. I added it to ox-beamer.el in-file documentation. You need to
add an entry appropriate for Beamer export. This entry doesn't need to
be named "beamer". For example, after the merge you add the following to
your init file:
#+begin_src emacs-lisp
'(add-to-list 'org-latex-classes
'("pres"
"\\documentclass[presentation]{beamer}
\[DEFAULT-PACKAGES]
\[PACKAGES]
\[EXTRA]"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")))
#+end_src
Then, the following in your buffer will suffice.
#+latex_class: pres
Regards,
--
Nicolas Goaziou
Re: [O] New exporter, beamer confusion
James Harkins writes: > Btw, *who* preferred \alert? (Orwell, Politics and the English Language: > "Never use the passive [voice] where you can use the active.") Obviously, me, as the author of the back-end. Org offers only one slot for "strong emphasis". I had to choose between bold and alert, and so I did. > Although I'm not happy about manual intervention to convert my prior work, > this is a good step toward consistency. It was odd, in the old framework, > to use headlines for bullet lists and org's numbered lists for numbered > lists. "An org list becomes an output list" is an easier rule to > explain. As explained in this thread, the H:num options item defines a limit between regular headlines and "low-level" headlines. Low level headlines are usually turned into lists during export. But, in the Beamer exporter, it is a better idea to turn them into blocks. Better as in "closer, by its properties, to an headline". > Still, I wonder if there is a way to make the new backend less unfriendly > toward lists. It's an interesting philosophical question: In what cases is > it better for the tool to adapt to the users' wishes, versus cases where > the tool should encourage (Are blocks in the result actually better than > lists? Who says so, and why should I take his or her word for it?) Nobody is saying that blocks are better than lists in the output. It's a matter of taste, isn't it? There are also ways to adapt the tool to your wishes (through hooks, filters, script, macros). > "Reasonably" for me would mean tweaking some configuration options and > perhaps changing a few minor details of the markup. If you have to change > the org document's structure (e.g., converting headlines to lists), it > isn't backward compatible. Then, by this definition, it isn't, indeed. > For comparison: Lilypond updates frequently break some details of backward > compatibility. So, they ship a "convert-ly" script to handle many of those > changes automatically. Even though the required change in our case are rather minimal, they mostly depend on the user configuration. Hence, I will not attempt to provide such a script. But I will provide instructions on how to make the transition, if they are needed. Regards, -- Nicolas Goaziou
Re: [O] New exporter, beamer confusion
Nicolas Goaziou writes: > Hello, > > Eric S Fraga writes: > >> Taking your updated version of the example document, I cannot get the >> exporter to generate a latex file that will compile because it is >> missing a documentclass directive. Is there something else that needs >> to be configured to support beamer, as in maybe org-e-latex-classes? > > Indeed. I added it to ox-beamer.el in-file documentation. You need to Thanks. This will indeed help. Should there be a check in the exporter, for latex based backends, if the document class expected is not defined? This would have made things a lot quicker to resolve in this case! Thanks again, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-904-g338046
Re: [O] New exporter, beamer confusion
On Feb 7, 2013 3:57 AM, "Nicolas Goaziou" wrote: > > Btw, *who* preferred \alert? (Orwell, Politics and the English Language: > > "Never use the passive [voice] where you can use the active.") > > Obviously, me, as the author of the back-end. Org offers only one slot > for "strong emphasis". I had to choose between bold and alert, and so > I did. Ok, and as long as I can configure it, no problem. Aside Re: Orwell, and now veering well off-topic, his point about passive voice is that it hides human agency and, in the worst cases, suggests that something simply "is objectively so" rather than "one or more people made it so, for reasons that may be subjective," or deflects responsibility à la "mistakes were made." Although the relationship to the present topic is only tangential, Orwell's caution is at least as relevant today as it was when he wrote it in 1946. I find for myself that following his advice [6 or 7 rules of thumb at the end of his essay] sounds a little alarm bell when my thinking is getting sloppy -- so I think it bears repeating. (Apologies to the scientific authors here, who "are trained" [oops!] to erase themselves from reports on their experimental procedures by using passive voice consistently...) In fact, it wasn't obvious to me whether it was simply your preference, or if an expert or authority on slideshow style recommends \alert over \textbf. In the latter case, I would want to know who and why, so I could read and then make up my own mind. > > "Reasonably" for me would mean tweaking some configuration options and > > perhaps changing a few minor details of the markup. If you have to change > > the org document's structure (e.g., converting headlines to lists), it > > isn't backward compatible. > > Then, by this definition, it isn't, indeed. Sure, and that's ok. My frustration stemmed from expecting more compatibility than there actually is. After adjusting my expectations, I can figure out how to make it work for me. hjh
Re: [O] New exporter, beamer confusion
> Should there be a check in the exporter, for latex based backends, if > the document class expected is not defined? This would have made things > a lot quicker to resolve in this case! What is an "expected document class"? Beamer export can happen with a "beamer" or an "article" (and probably others) document class. There's no real way to know if the class used is correct. Regards, -- Nicolas Goaziou
Re: [O] New exporter, beamer confusion
Hi,
> LaTeX class is never unspecified because `beamer' back-end is
> a derivative of `latex', and, as such, `org-latex-default-class' will be
> used. `beamer' could specify its own default class, but that class would
> still need to be defined in `org-latex-classes'.
Sure, it should be in the default list. What is the drawback?
> '("beamer"
> "\\documentclass[presentation]{beamer}
> \[DEFAULT-PACKAGES]
> \[PACKAGES]
> \[EXTRA]"
> ("\\section{%s}" . "\\section*{%s}")
> ("\\subsection{%s}" . "\\subsection*{%s}")
> ("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
Looks reasonable.
> > Plain latex export is more problematic because several options are
> > reasonable, but I can't see beamer export with an article class ...
>
> But it exists, and is documented in the Beamer User Guide. See section
> "21.2. Creating Handouts Using the Article Mode".
Yes, I know that, but the thing is, from a given org-file, I would expect
beamer export to make the slides and 'plain' latex export to create the
handout. Maybe it is difficult to achieve but it feels like the most useable
setup. Is it at all doable?
/v
Re: [O] New exporter, beamer confusion
Vincent Beffara writes: > Sure, it should be in the default list. What is the drawback? The default list is defined in ox-latex.el, which doesn't know anything about ox-beamer.el. The drawback is that it doesn't seem clean to me. I think it's better to make it a fallback value hardcoded (or in a defconst) in ox-beamer.el instead. > Yes, I know that, but the thing is, from a given org-file, I would > expect beamer export to make the slides and 'plain' latex export to > create the handout. Maybe it is difficult to achieve but it feels like > the most useable setup. Is it at all doable? If the author is cautious about keywords used (i.e. #+BEAMER: or #+LATEX:), it should be possible to export the same document with either `beamer' or `latex' back-end. Though, I don't know how much difference there would be between the output from `latex' and a Beamer handout produced with "article" class. Regards, -- Nicolas Goaziou
Re: [O] New exporter, beamer confusion
Nicolas Goaziou writes: > If the author is cautious about keywords used (i.e. #+BEAMER: or > #+LATEX:), it should be possible to export the same document with either > `beamer' or `latex' back-end. Though, I don't know how much difference > there would be between the output from `latex' and a Beamer handout > produced with "article" class. There is an auxiliary package called beamerarticle. It's neat. It's described in 21.2.1 in the beamer guide v.3.26. And there's an example in the file conference-ornate-20min.en.tex which is shipped with beamer. Cool with the #+BEAMER. I didn't know about this, but it's super nice. The other day I was lookking for a replacement to #+BEAMER_HEADER (I think that was what it was called), which existed with the 'old' exporter. Does this variable exist in Beamer yet? Thanks a lot for your work Nicolas. It's super cool! –Rasmus -- In theory, practice and theory are the same. In practice they are not
Re: [O] New exporter, beamer confusion
Hello, Rasmus writes: > Nicolas Goaziou writes: > >> If the author is cautious about keywords used (i.e. #+BEAMER: or >> #+LATEX:), it should be possible to export the same document with either >> `beamer' or `latex' back-end. Though, I don't know how much difference >> there would be between the output from `latex' and a Beamer handout >> produced with "article" class. > > > There is an auxiliary package called beamerarticle. It's neat. It's > described in 21.2.1 in the beamer guide v.3.26. And there's an > example in the file conference-ornate-20min.en.tex which is shipped > with beamer. > > Cool with the #+BEAMER. I didn't know about this, but it's super > nice. The other day I was lookking for a replacement to > #+BEAMER_HEADER (I think that was what it was called), which existed > with the 'old' exporter. Does this variable exist in Beamer yet? There is the #+LATEX_HEADER:. Is a keyword specific to Beamer required? It would by symmetric with #+BEAMER: but I have never needed it before. Regards, -- Nicolas Goaziou
Re: [O] New exporter, beamer confusion
Nicolas,
> There is the #+LATEX_HEADER:. Is a keyword specific to Beamer
> required? It would by symmetric with #+BEAMER: but I have never
> needed it before.
Something like
#+LATEX_HEADER:\AtBeginSection[]{\frame{\thispagestyle{empty}\tableofcontents[currentsection]}}
is not interesting to a LaTeX article output, but perhpas in a Beamer.
Or it might want to use a more 'fun' font for my slides while sticking
with kpfonts for the article version, e.g.
#+BEAMER_HEADER:\usepackage[math]{anttor}
#+LATEX_HEADER:\usepackage[light]{kpfonts}
But perhaps (probably!) it could be sorted out on the LaTeX side,
e.g. via beamerarticle.
–Rasmus
--
Vote for proprietary math!
Re: [O] New exporter, beamer confusion
Nicolas Goaziou writes: >> Should there be a check in the exporter, for latex based backends, if >> the document class expected is not defined? This would have made things >> a lot quicker to resolve in this case! > > What is an "expected document class"? Beamer export can happen with > a "beamer" or an "article" (and probably others) document class. There's > no real way to know if the class used is correct. Sure. I didn't suggest that there should be a default (although as others have suggested, a default of "beamer" would be reasonable). My point was simply that generating a latex file with no "documentclass" line doesn't make much sense and this omission should be caught by the exporter. It would help any user more quickly figure out what is wrong with the org file being exported. Well, it would have helped me! ;-) Arguably, this is not a problem with the beamer exporter but the latex one instead. In any case, I'd like to say thanks! I had a presentation to give earlier today and wrote it from scratch using the new exporter. After the initial hiccoughs (as documented on this list) and my not having noted earlier that the ATTR_* syntax had changed (e.g. :options width=... for images), everything went like a charm. eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-904-g338046
Re: [O] New exporter, beamer confusion
Rasmus writes:
>> There is the #+LATEX_HEADER:. Is a keyword specific to Beamer
>> required? It would by symmetric with #+BEAMER: but I have never
>> needed it before.
>
>
> Something like
>
> #+LATEX_HEADER:\AtBeginSection[]{\frame{\thispagestyle{empty}\tableofcontents[currentsection]}}
>
> is not interesting to a LaTeX article output, but perhpas in a Beamer.
> Or it might want to use a more 'fun' font for my slides while sticking
> with kpfonts for the article version, e.g.
>
> #+BEAMER_HEADER:\usepackage[math]{anttor}
> #+LATEX_HEADER:\usepackage[light]{kpfonts}
>
> But perhaps (probably!) it could be sorted out on the LaTeX side,
> e.g. via beamerarticle.
I have added BEAMER_HEADER keywords.
Regards,
--
Nicolas Goaziou
