[-- Attachment #1: Type: text/plain, Size: 763 bytes --] Hi all, I'm trying to reference a slide using the beamer new exporter. Each frame gets its own label automagically (sec-#-##). Is there a way to reference those labels later on ? Using emacs-lisp ? Or ? I tried another way to solve my problem and wanted to define my own label on a frame : ** My frame titles :B_frame: :PROPERTIES: :BEAMER_opt: label=tcs :BEAMER_env: frame :END: Unfortunately, the new latex/beamer exporter does not seem to check that the user may have wanted to put his/her own label on a frame and it adds its own label to the user defined one. It is not that difficult to patch org-e-beamer--format-frame to avoid adding label when the user provides its own, but is it the right thing to do ? Greetings, -- Fabrice [-- Attachment #2: Type: text/html, Size: 1043 bytes --]
Hello, Fabrice Popineau <fabrice.popineau@supelec.fr> writes: > I'm trying to reference a slide using the beamer new exporter. > Each frame gets its own label automagically (sec-#-##). > Is there a way to reference those labels later on ? Using emacs-lisp ? > Or ? You refer to these labels when you create an internal link (fuzzy, by custom-id, or by id) to the headline. So the idea is that you don't have to bother with label's name. Unfortunately, there's one limitation for now: it isn't possible to specify an overlay for the target. For example: --8<---------------cut here---------------start------------->8--- #+OPTIONS: H:1 * Frame 1 :PROPERTIES: :CUSTOM_ID: frame1 :END: #+ATTR_BEAMER: :overlay "+-" - item 1 - item 2 * Frame 2 [[*Frame 1][Link to first frame]] (1) [[#frame1][@@e-beamer:<2>@@Link to first frame]] (2) --8<---------------cut here---------------end--------------->8--- (1) will produce \hyperlink{sec-1}{Link to first frame} (2) will produce \hyperlink<2>{sec-1}{Link to first frame} (*) At the moment, there's no way to produce: \hyperlink{sec-1<2>}{Link to first frame, second overlay} (+) I may swap the export-snippet usage in second case, if (*) is less useful than (+). Note that I hardly, if ever, use links in my presentations so `org-e-beamer-link' is probably sub-optimal. > I tried another way to solve my problem and wanted to define my own label > on a frame : > > ** My frame titles :B_frame: > :PROPERTIES: > :BEAMER_opt: label=tcs > :BEAMER_env: frame > :END: > > Unfortunately, the new latex/beamer exporter does not seem to check that > the user may have wanted to put his/her > own label on a frame and it adds its own label to the user defined one. > It is not that difficult to patch org-e-beamer--format-frame to avoid > adding label when the user provides its own, but is it > the right thing to do ? Considering the remark above, I'm don't think that's the best way to handle the problem. On the other hand, "label" is an option and should be treated as such (that is, an user should be able to provide its own value for it). It is implemented now. Regards, -- Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 1355 bytes --] > > > Unfortunately, the new latex/beamer exporter does not seem to check that > > the user may have wanted to put his/her > > own label on a frame and it adds its own label to the user defined one. > > It is not that difficult to patch org-e-beamer--format-frame to avoid > > adding label when the user provides its own, but is it > > the right thing to do ? > > Considering the remark above, I'm don't think that's the best way to > handle the problem. On the other hand, "label" is an option and should > be treated as such (that is, an user should be able to provide its own > value for it). It is implemented now. > Well, thanks for this It solves an easy case that has already asked for in the past. Now I can do : * section ** My frame title :B_frame: :PROPERTIES: :BEAMER_opt: label=tcs :BEAMER_env: frame :END: Some text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. * section :B_ignoreheading: #+BEAMER: \againframe<2>{tcs} ** Following frame etc. Not as clean as we might want it, but it is working ok. I had to add an "invisible" section else the againframe is not exported between frames, but inside the preceding frame. I don't think it was possible before. I think it may prove useful to be able to chose the label for the frame. -- Fabrice [-- Attachment #2: Type: text/html, Size: 3086 bytes --]
Fabrice Popineau <fabrice.popineau@supelec.fr> writes:
> Well, thanks for this It solves an easy case that has already asked for in
> the past.
> Now I can do :
>
> * section
> ** My frame title :B_frame:
> :PROPERTIES:
> :BEAMER_opt: label=tcs
> :BEAMER_env: frame
> :END:
>
> Some text. Some text. Some text. Some text.
> Some text. Some text. Some text. Some text.
>
> * section :B_ignoreheading:
> #+BEAMER: \againframe<2>{tcs}
>
> ** Following frame
> etc.
>
> Not as clean as we might want it, but it is working ok. I had to add an
> "invisible" section
> else the againframe is not exported between frames, but inside the
> preceding frame.
Interesting. What about providing an "againframe" environment (on par
with "appendix", "note", etc.)?
It would use "BEAMER_act" property to set the overlay specification, and
a "BEAMER_ref" property using link syntax to refer to a particular
section. Here's an example:
--8<---------------cut here---------------start------------->8---
* section
** My frame title :B_frame:
:PROPERTIES:
:BEAMER_env: frame
:END:
Some text. Some text. Some text. Some text.
Some text. Some text. Some text. Some text.
** section :B_againframe:
:PROPERTIES:
:BEAMER_env: againframe
:BEAMER_act: 2
:BEAMER_ref: *My frame title
:END:
This section will create "\againframe<2>{sec-1-2}".
** Following frame
etc.
--8<---------------cut here---------------end--------------->8---
This is not really cleaner than your workaround, but at least, it feels
more integrated. Another advantage is that you don't need to know the
label of the frame being resumed.
For convenience, when asking for an "againframe",
`org-e-beamer-select-environment' would always ask for "act" and "ref"
properties, since those are mandatory anyway.
I don't mind implementing this, but I'm not sure it's worth the
(although limited) hassle.
--
Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 434 bytes --] > > Interesting. What about providing an "againframe" environment (on par > with "appendix", "note", etc.)? > > It would use "BEAMER_act" property to set the overlay specification, and > a "BEAMER_ref" property using link syntax to refer to a particular > section. Here's an example: > > That would be a nice idea. This againframe is quite used. And your proposal is much cleaner wrt to the org syntax than my current hack. Fabrice [-- Attachment #2: Type: text/html, Size: 736 bytes --]
Fabrice Popineau <fabrice.popineau@supelec.fr> writes:
>> Interesting. What about providing an "againframe" environment (on par
>> with "appendix", "note", etc.)?
>>
>> It would use "BEAMER_act" property to set the overlay specification, and
>> a "BEAMER_ref" property using link syntax to refer to a particular
>> section. Here's an example:
>>
>>
> That would be a nice idea. This againframe is quite used.
> And your proposal is much cleaner wrt to the org syntax than my current
> hack.
I've added support for "againframe", as specified above. Is it working
as expected, or am I missing something?
--
Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --] Seems ok to me. Great ! Fabrice 2012/9/4 Nicolas Goaziou <n.goaziou@gmail.com> > Fabrice Popineau <fabrice.popineau@supelec.fr> writes: > > >> Interesting. What about providing an "againframe" environment (on par > >> with "appendix", "note", etc.)? > >> > >> It would use "BEAMER_act" property to set the overlay specification, and > >> a "BEAMER_ref" property using link syntax to refer to a particular > >> section. Here's an example: > >> > >> > > That would be a nice idea. This againframe is quite used. > > And your proposal is much cleaner wrt to the org syntax than my current > > hack. > > I've added support for "againframe", as specified above. Is it working > as expected, or am I missing something? > > -- > Nicolas Goaziou > -- Fabrice Popineau ----------------------------- SUPELEC Département Informatique 3, rue Joliot Curie 91192 Gif/Yvette Cedex Tel direct : +33 (0) 169851950 Standard : +33 (0) 169851212 ------------------------------ [-- Attachment #2: Type: text/html, Size: 1751 bytes --]