emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [Orgmode] Re: New beamer support


From: Darlan Cavalcante Moreira
Subject: Re: [Orgmode] Re: New beamer support
Date: Thu, 07 Jan 2010 15:03:21 -0300
User-agent: Wanderlust/2.15.6 (Almost Unreal) Emacs/23.1 Mule/6.0 (HANACHIRUSATO)

I agree that it is useful to have an easy way to specify one or more options for
every frame, but from the beamer manual I understand that these options where
created for specific cases and IMHO org shouldn't include any frame option by
default.

About the fragile option, the beamer manual tells you when to use it, but
doesn't mention any drawbacks of its use. I also tried searching for problems
with the fragile option but I found nothing and therefore I do not know the
implications of enabling the fragile option in every frame. However, if there is
no drawbacks then I wonder why the beamer author didn't make it the default
behavior.

Maybe it is better to ask in a beamer mailing list the implications of setting
this option for every frame.

- Darlan Cavalcante Moreira

At Thu, 07 Jan 2010 17:16:55 +0100,
Sébastien Vauban <address@hidden> wrote:
> 
> Hi Carsten and Darlan,
> 
> Carsten Dominik wrote:
> > On Jan 7, 2010, at 3:39 PM, Darlan Cavalcante Moreira wrote:
> >>> Carsten Dominik wrote:
> >>>> On Jan 6, 2010, at 5:22 PM, Sébastien Vauban wrote:
> >>>>> Carsten Dominik wrote:
> >>>>>>
> >>>>>> there is now a new option org-beamer-frame-default-options
> >>>>>
> >>>>> Though, wouldn't it be better to explicitly add something like:
> >>>>>
> >>>>> --8<---------------cut here---------------start------------->8---
> >>>>> #+BEAMER_FRAME_EXTRA_OPTIONS: [allowframebreaks]
> >>>>> --8<---------------cut here---------------end--------------->8---
> >>>>
> >>>> Yes, that would make sense if it is a frequently used feature. I like to
> >>>> hesitate with introducing these special customizations until I am
> >>>> convinced that this is used reasonably often. Otherwise I would have to
> >>>> have 1000 of the special lines, approximately.
> >>>>
> >>>> Question to all: How likely is the use of a default option you'd want to
> >>>> have on *every* frame?
> >>>
> >>> The problem is similar to the `fragile' option. Either we can detect the
> >>> "overflow" (and the automatically add the option only when needed), or we
> >>> must add it everywhere in order to ensure we won't have text cut.
> >>>
> >>> It's a bit different from when we directly edit beamer files. We compile
> >>> often and we see the problem appearing.
> >>>
> >>> Here, with Org, we would just work in Org only, and publish once at the
> >>> end. A bit more easy to be aware that some text may have pass away.
> >>>
> >>> As #+BIND works, I can imagine living quite honestly the way it currently
> >>> is, but I let the others decide upon this.
> >>
> >> I don't think org-mode should try to detect when to use any of the frame
> >> options in beamer. This could get into the way more then helping, specially
> >> the allowframebreaks option.
> 
> I don't see what the problem could be of enabling (or having the possibility
> to enable) that option on every slide by default.
> 
> 
> >> In fact, the beamer manual tells you not to use the allowframebreaks option
> >> except for long bibliographies (well, it also tells you not to use long
> >> bibliographies) and I agree with this.
> 
> Just read page 56 of the beamer manual. Makes (some) sense, yes.
> 
> 
> >> In a presentation you have to choose carefully what you will put in each
> >> slide and always leaving this to beamer with the allowframebreaks is not a
> >> good approach.
> 
> Still, I don't really see which problem this would bring, even if that's not
> the purest manner of writing slides.
> 
> BTW, yes, I saw one problem. There is some orphan title on the bottom of one
> page, and the contents on the top of the next one. Maybe, though, that can be
> easily fixed by `nobreaks' macros (either manual or automatic).
> 
> 
> >> In addition, I agree that when working in a presentation with org- mode you
> >> compile much less, but you should still compile sometimes to see if the
> >> slides are well designed.
> 
> That's really the point. Contents vs Presentation.
> 
> At least, my biggest problem is that I like to be warned somehow (but how?)
> that such a problem is occurring, that some slide's contents is just too big
> to stay on one page.
> 
> I would quite not like to have to scan the full presentation, comparing the
> Org source and the beamer PDF in order to see if every line is in both. Don't
> forget we can author such a presentation with multiple persons working on the
> Org source, and that (as well) it's never always right or wrong: *changing of
> theme* brings fonts differences or margins *differences that can hide lines
> that were supposed to be visible*.
> 
> I basically understand your point, but my objection is about having constantly
> to check the results for missing lines.
> 
> 
> >> I don't know if Carsten has plans to implement this, but a "fast preview"
> >> that exports and compiles only the current slide could be useful here.
> >>
> >> At last, I have a small feature request that would help organizing the
> >> information among the slides. Right now you can use Alt+up/down arrow to
> >> move a list item in a heading, but org does not allow passing beyond a
> >> heading limit. This makes sense in a normal org file and is very useful,
> >> but when writing a presentation with org this restriction can get into the
> >> way. This is not a big deal, but maybe others are also interested in this.
> 
> Having to spend more time to move items from one slide to the other would make
> such a feature useful for me as well, I guess.
> 
> 
> > Do you also think I should not try to add the fragile option automatically?
> 
> Not sure if we can apply the above reasoning to that one. The question
> certainly merits to be asked, but I'm not enlightened enough to give an
> answer.
> 
> That's true that if we say: "it's up to the user" for the slide preparation,
> we can apply that to everything, or consider the automatic stuff to be really
> good.
> 
> Just don't know.
> 
> Best regards,
>   Seb
> 
> -- 
> Sébastien Vauban
> 
> 
> 
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode




reply via email to

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