Re: New beamer support

["Sébastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>]

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.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode