* [beamer] When are :BEAMER_envargs: used or ignored?
@ 2012-02-27 7:07 James Harkins
2012-04-25 4:41 ` Eric Fraga
0 siblings, 1 reply; 8+ messages in thread
From: James Harkins @ 2012-02-27 7:07 UTC (permalink / raw)
To: emacs-orgmode
According to the online documentation [1], it seems that :BEAMER_envargs: should apply to all Beamer environments:
~~~
BEAMER_envargs
The beamer-special arguments that should be used for the environment, like [t] or [<+->] of <2-3>. If the BEAMER_col property is also set, something like C[t] can be added here as well to set an options argument for the implied columns environment. c[t] or c<2-> will set an options for the implied column environment.
~~~
This does work in the example presentation at [1], but it seems only for B_block entries. I was trying to use B_beamercolorbox, where presumably the color selections (fg=, bg=) should be environment arguments, but this is ignored. What's more, if I take the colors out of the color box's envargs and replace it with another argument syntax -- <2-> -- that definitely works with B_block, this is also ignored. So it seems, if you wanted to have a colorbox appear in a later overlay, you would be screwed (would have to write the LaTeX by hand).
A bit confused.
Or, the simple question -- how do you set the colors of a color box in Beamer export?
Oh, wait, I just figured it out... though you would have to admit, this is not remotely obvious.
** Frame 2 \\ where we will not use columns
#+LaTeX: \setbeamercolor{ybg}{bg=yellow}
*** ybg :B_beamercolorbox:
Please test this stuff!
:PROPERTIES:
:BEAMER_env: beamercolorbox
:END:
It kind of strikes me like an epic hack: you have to name the headline after the Beamer color ID, instead of naming the headline after the content... not very /org/anized.
Worth a bug report or feature request?
hjh
[1] http://orgmode.org/manual/Beamer-class-export.html
--
James Harkins /// dewdrop world
jamshark70@dewdrop-world.net
http://www.dewdrop-world.net
"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [beamer] When are :BEAMER_envargs: used or ignored?
2012-02-27 7:07 [beamer] When are :BEAMER_envargs: used or ignored? James Harkins
@ 2012-04-25 4:41 ` Eric Fraga
2012-04-25 10:09 ` James Harkins
0 siblings, 1 reply; 8+ messages in thread
From: Eric Fraga @ 2012-04-25 4:41 UTC (permalink / raw)
To: James Harkins; +Cc: emacs-orgmode
James Harkins <jamshark70@gmail.com> writes:
> According to the online documentation [1], it seems
> that :BEAMER_envargs: should apply to all Beamer environments:
And it does generally although I have tried setting it (for your example
below) to {ybg} and it disappears. If I set it to [ybg], it does appear
in the exported latex. I haven't delved into the beamer export code in
a long while but it must be checking for constructs of the form [...] or
<...>, I would guess.
In any case, addressing your real question:
[...]
> Or, the simple question -- how do you set the colors of a color box in
> Beamer export?
> Oh, wait, I just figured it out... though you would have to admit,
> this is not remotely obvious.
> ** Frame 2 \\ where we will not use columns
> #+LaTeX: \setbeamercolor{ybg}{bg=yellow}
> *** ybg :B_beamercolorbox:
> Please test this stuff!
> :PROPERTIES:
> :BEAMER_env: beamercolorbox
> :END:
>
> It kind of strikes me like an epic hack: you have to name the headline
> after the Beamer color ID, instead of naming the headline after the
> content... not very /org/anized.
Well, the problem is that a beamercolorbox is *not* a block and does not
expect a title parameter. It actually expects only a colour (well, a
beamer colour structure, to be precise, such as the one you have
defined). What is /org/ expected to do with the entry you specify?
To achieve what you want (maybe, as I am not clear exactly what you want
;-), you should probably define a block *within* the beamercolorbox or
vice versa. For instance:
--8<---------------cut here---------------start------------->8---
** Frame 2 \\ where we will not use columns
*** ybg :B_beamercolorbox:
:PROPERTIES:
:BEAMER_env: beamercolorbox
:END:
**** Title :B_block:
:PROPERTIES:
:BEAMER_env: block
:END:
Please test this stuff!
--8<---------------cut here---------------end--------------->8---
> Worth a bug report or feature request?
It is not a bug, IMO.
Whether it should be a feature request or not is debatable. The syntax
is, at present, fairly straightforward in that the headline text becomes
the argument to the environment defined. What that environment does
with the argument is obviously up to the environment itself!
HTH,
eric
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [beamer] When are :BEAMER_envargs: used or ignored?
2012-04-25 4:41 ` Eric Fraga
@ 2012-04-25 10:09 ` James Harkins
2012-04-25 12:49 ` James Harkins
2012-04-25 13:15 ` Eric Fraga
0 siblings, 2 replies; 8+ messages in thread
From: James Harkins @ 2012-04-25 10:09 UTC (permalink / raw)
To: emacs-orgmode
At Wed, 25 Apr 2012 14:11:51 +0930,
Eric Fraga wrote:
> > It kind of strikes me like an epic hack: you have to name the headline
> > after the Beamer color ID, instead of naming the headline after the
> > content... not very /org/anized.
>
> Well, the problem is that a beamercolorbox is *not* a block and does not
> expect a title parameter. It actually expects only a colour (well, a
> beamer colour structure, to be precise, such as the one you have
> defined). What is /org/ expected to do with the entry you specify?
If the subtree is folded, then the headline shows the color descriptor but nothing about the content of the subtree! That's some distance away from "an outline works like your brain."
It's not that I can't get the right output. It *is* a pretty stark inconsistency against org-mode's governing principle. Here, formatting information that is irrelevant to content is promoted to be the *most important thing* (the headline) of that subtree. What I need to see, in order to understand the structure of the content at a glance -- this IMO is org-mode's genius -- is hidden if the subtree is folded. Hm?
It strikes me as flawed design.
> > Worth a bug report or feature request?
>
> It is not a bug, IMO.
Okay, it's not a bug in the strict sense of a feature that doesn't behave as designed. I would say it's a d@mn ugly design.
> Whether it should be a feature request or not is debatable. The syntax
> is, at present, fairly straightforward in that the headline text becomes
> the argument to the environment defined.
I think "the headline text becomes the argument..." is the opposite of straightforward. :-)
It's also a matter of incomplete documentation. The syntax is /perhaps/ straightforward, *after* spending some time wondering why it didn't work to put the color into an environment argument (as one might reasonably guess), and then spending more time constructing some tests and looking at the *.tex output to find out which bit of org text gets put where in the TeX code.
C-c C-b lists 19 ways to tag headlines for Beamer environments. [1] doesn't describe any of them. I do understand about volunteer documentation efforts (if days were 48 hours long, I still wouldn't be able to write more than half of the documentation I want to contribute to SuperCollider [2]), but I can't help feeling something is missing here.
James
[1] http://orgmode.org/manual/Beamer-class-export.html#Beamer-class-export
[2] http://supercollider.sourceforge.net
--
James Harkins /// dewdrop world
jamshark70@dewdrop-world.net
http://www.dewdrop-world.net
"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [beamer] When are :BEAMER_envargs: used or ignored?
2012-04-25 10:09 ` James Harkins
@ 2012-04-25 12:49 ` James Harkins
2012-04-26 8:14 ` Eric Fraga
2012-04-25 13:15 ` Eric Fraga
1 sibling, 1 reply; 8+ messages in thread
From: James Harkins @ 2012-04-25 12:49 UTC (permalink / raw)
To: emacs-orgmode
At Wed, 25 Apr 2012 18:09:18 +0800,
James Harkins wrote:
> > Whether it should be a feature request or not is debatable. The syntax
> > is, at present, fairly straightforward in that the headline text becomes
> > the argument to the environment defined.
>
> I think "the headline text becomes the argument..." is the opposite of straightforward. :-)
OK, wait, I get it:
\begin{alertblock}{HEADLINE TEXT HERE}
\begin{beamercolorbox}{HEADLINE TEXT HERE}
OK, it's a consistent translation. But I still have the issue with it that the user has to adapt the org-file structure to suit beamer's requirements. Org-mode is all about reflecting the content in a way that makes sense FIRST to humans, and only secondarily to exporting engines.
hjh
--
James Harkins /// dewdrop world
jamshark70@dewdrop-world.net
http://www.dewdrop-world.net
"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [beamer] When are :BEAMER_envargs: used or ignored?
2012-04-25 12:49 ` James Harkins
@ 2012-04-26 8:14 ` Eric Fraga
2012-04-26 9:51 ` James Harkins
0 siblings, 1 reply; 8+ messages in thread
From: Eric Fraga @ 2012-04-26 8:14 UTC (permalink / raw)
To: James Harkins; +Cc: emacs-orgmode
James Harkins <jamshark70@gmail.com> writes:
> At Wed, 25 Apr 2012 18:09:18 +0800,
> James Harkins wrote:
>> > Whether it should be a feature request or not is debatable. The syntax
>> > is, at present, fairly straightforward in that the headline text becomes
>
>> > the argument to the environment defined.
>>
>> I think "the headline text becomes the argument..." is the opposite of straightforward. :-)
>
> OK, wait, I get it:
>
> \begin{alertblock}{HEADLINE TEXT HERE}
>
> \begin{beamercolorbox}{HEADLINE TEXT HERE}
>
> OK, it's a consistent translation.
Yes.
> But I still have the issue with it
> that the user has to adapt the org-file structure to suit beamer's
> requirements. Org-mode is all about reflecting the content in a way
> that makes sense FIRST to humans, and only secondarily to exporting
> engines.
I agree. However, the problems arise when exporting because of
fundamentally different structures between org and the export
target. This is why we have the various kludges (if people can forgive
me for calling them this) like ATTR_HTML and ATTR_LATEX. There is no
easy or elegant mechanism in org for satisfying all the different export
target requirements that are fundamentally inconsistent with org's
outline heritage.
For this particular case, it could be that the beamercolorbox
environment could be made to expect a specific PROPERTY, much like the
column environment does. The question would then be: what should the
headline be used for as beamercolorbox has no real text content
argument.
I would guess that if you could suggest a consistent and more elegant
solution, it would be considered favourably and maybe somebody would
take it up and implement it. No promises, however!
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [beamer] When are :BEAMER_envargs: used or ignored?
2012-04-26 8:14 ` Eric Fraga
@ 2012-04-26 9:51 ` James Harkins
2012-04-26 11:15 ` Sebastien Vauban
0 siblings, 1 reply; 8+ messages in thread
From: James Harkins @ 2012-04-26 9:51 UTC (permalink / raw)
To: emacs-orgmode
At Thu, 26 Apr 2012 17:44:56 +0930,
Eric Fraga wrote:
> > But I still have the issue with it
> > that the user has to adapt the org-file structure to suit beamer's
> > requirements. Org-mode is all about reflecting the content in a way
> > that makes sense FIRST to humans, and only secondarily to exporting
> > engines.
>
> I agree. However, the problems arise when exporting because of
> fundamentally different structures between org and the export
> target. This is why we have the various kludges (if people can forgive
> me for calling them this) like ATTR_HTML and ATTR_LATEX. There is no
> easy or elegant mechanism in org for satisfying all the different export
> target requirements that are fundamentally inconsistent with org's
> outline heritage.
I understand. An elegant solution would take some mulling over (especially considering that I've only recently started using the export features, and my knowledge of LaTeX is superficial at best). In the meantime, I can live with the current situation.
That the headline title is used for the color specification is probably not such an unbearable thing in practice. How many color boxes are there likely to be on one slide? (Meaning, if you're tempted to load up a slide with so many color boxes that you get confused about the content, maybe the content needs to be restructured.) If it's the only color box on the slide, quite likely you can infer its content from the frame title or other headings nearby.
It just struck me as a loose end, and I'm glad I asked about it, because I have a better understanding of the issues now.
> For this particular case, it could be that the beamercolorbox
> environment could be made to expect a specific PROPERTY, much like the
> column environment does. The question would then be: what should the
> headline be used for as beamercolorbox has no real text content
> argument.
There are other beamer tags that don't use the headline text, namely quote and quotation. According to the beamer user guide, there's no place for the headline:
\begin{quote}<action specification>
environment contents
\end{quote}
Compared to
\begin{block}<action specification>{block title}<action specification>
environment contents
\end{block}
So, there is already a situation where you have to put some dummy text into the headline that won't appear. Maybe there could be special handling for title-less environments, so that the headline would become the environment contents and colorbox could take its color from a property...
> I would guess that if you could suggest a consistent and more elegant
> solution, it would be considered favourably and maybe somebody would
> take it up and implement it. No promises, however!
... but the elegance of that approach would be debatable, I suppose.
James
--
James Harkins /// dewdrop world
jamshark70@dewdrop-world.net
http://www.dewdrop-world.net
"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [beamer] When are :BEAMER_envargs: used or ignored?
2012-04-26 9:51 ` James Harkins
@ 2012-04-26 11:15 ` Sebastien Vauban
0 siblings, 0 replies; 8+ messages in thread
From: Sebastien Vauban @ 2012-04-26 11:15 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi James,
James Harkins wrote:
> At Thu, 26 Apr 2012 17:44:56 +0930,
> Eric Fraga wrote:
>> > But I still have the issue with it
>> > that the user has to adapt the org-file structure to suit beamer's
>> > requirements. Org-mode is all about reflecting the content in a way
>> > that makes sense FIRST to humans, and only secondarily to exporting
>> > engines.
>>
>> I agree. However, the problems arise when exporting because of
>> fundamentally different structures between org and the export
>> target. This is why we have the various kludges (if people can forgive
>> me for calling them this) like ATTR_HTML and ATTR_LATEX. There is no
>> easy or elegant mechanism in org for satisfying all the different export
>> target requirements that are fundamentally inconsistent with org's
>> outline heritage.
>
> I understand. An elegant solution would take some mulling over (especially
> considering that I've only recently started using the export features, and my
> knowledge of LaTeX is superficial at best). In the meantime, I can live with
> the current situation.
>
> That the headline title is used for the color specification is probably not
> such an unbearable thing in practice. How many color boxes are there likely to
> be on one slide? (Meaning, if you're tempted to load up a slide with so many
> color boxes that you get confused about the content, maybe the content needs
> to be restructured.) If it's the only color box on the slide, quite likely you
> can infer its content from the frame title or other headings nearby.
>
> It just struck me as a loose end, and I'm glad I asked about it, because I
> have a better understanding of the issues now.
>
>> For this particular case, it could be that the beamercolorbox
>> environment could be made to expect a specific PROPERTY, much like the
>> column environment does. The question would then be: what should the
>> headline be used for as beamercolorbox has no real text content
>> argument.
>
> There are other beamer tags that don't use the headline text, namely quote and
> quotation. According to the beamer user guide, there's no place for the
> headline:
>
> \begin{quote}<action specification>
> environment contents
> \end{quote}
>
> Compared to
>
> \begin{block}<action specification>{block title}<action specification>
> environment contents
> \end{block}
>
> So, there is already a situation where you have to put some dummy text into
> the headline that won't appear.
And, in Org-Beamer, you have the explicit tag `b_ignore' as well, to ignore
the entry title, using the contents only.
> Maybe there could be special handling for title-less environments, so that
> the headline would become the environment contents and colorbox could take
> its color from a property...
I don't find that a particularly attractive option, since you would end up
with very long headlines (often more than 80 characters) and you would not be
able to have multiline (or multiparagraph) contents.
Best regards,
Seb
--
Sebastien Vauban
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [beamer] When are :BEAMER_envargs: used or ignored?
2012-04-25 10:09 ` James Harkins
2012-04-25 12:49 ` James Harkins
@ 2012-04-25 13:15 ` Eric Fraga
1 sibling, 0 replies; 8+ messages in thread
From: Eric Fraga @ 2012-04-25 13:15 UTC (permalink / raw)
To: James Harkins; +Cc: emacs-orgmode
James Harkins <jamshark70@gmail.com> writes:
> At Wed, 25 Apr 2012 14:11:51 +0930,
> Eric Fraga wrote:
>> > It kind of strikes me like an epic hack: you have to name the headline
>> > after the Beamer color ID, instead of naming the headline after the
>
>> > content... not very /org/anized.
>>
>> Well, the problem is that a beamercolorbox is *not* a block and does not
>> expect a title parameter. It actually expects only a colour (well, a
>> beamer colour structure, to be precise, such as the one you have
>> defined). What is /org/ expected to do with the entry you specify?
>
> If the subtree is folded, then the headline shows the color descriptor
> but nothing about the content of the subtree! That's some distance
> away from "an outline works like your brain."
Yes. You could, of course, turn my suggestion inside out: have the
block first and then the coloured box as a subheading... then the main
heading would at least give you an indication of what follows.
> It's not that I can't get the right output. It *is* a pretty stark
> inconsistency against org-mode's governing principle. Here, formatting
> information that is irrelevant to content is promoted to be the *most
> important thing* (the headline) of that subtree. What I need to see,
> in order to understand the structure of the content at a glance --
> this IMO is org-mode's genius -- is hidden if the subtree is
> folded. Hm?
>
> It strikes me as flawed design.
Well, it's a compromise, I would suggest. most compromises can indeed
be considered flawed design from an aesthetic point of view. org is
based on outlines, not on containers. Latex is based on containers
(mostly). This basic inconsistency comes up all the time on this list
(e.g. a lower level entry can only be ended by starting a new headline
at the same or higher level).
>> > Worth a bug report or feature request?
>>
>> It is not a bug, IMO.
>
> Okay, it's not a bug in the strict sense of a feature that doesn't behave as designed. I would say it's a d@mn ugly design.
Fine. That's one view. I would suggest that maybe you could suggest a
better design, remembering, of course, that the basis of org is an
outliner...?
> It's also a matter of incomplete documentation. The syntax is
Indeed. And I am partly to blame for this. I do have a number of
outstanding TODO items with respect to the documentation of beamer
support in org. But I also do have a real job which, unfortunately,
seems to take increasingly more hours every day...
> /perhaps/ straightforward, *after* spending some time wondering why it
> didn't work to put the color into an environment argument (as one
> might reasonably guess), and then spending more time constructing some
> tests and looking at the *.tex output to find out which bit of org
> text gets put where in the TeX code.
>
> C-c C-b lists 19 ways to tag headlines for Beamer environments. [1]
Yes, because the documentation was written to illustrate how org could
support beamer; a comprehensive document has never been written. I
would be happy if you would consider contributing to the documentation?
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-04-26 11:15 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-27 7:07 [beamer] When are :BEAMER_envargs: used or ignored? James Harkins
2012-04-25 4:41 ` Eric Fraga
2012-04-25 10:09 ` James Harkins
2012-04-25 12:49 ` James Harkins
2012-04-26 8:14 ` Eric Fraga
2012-04-26 9:51 ` James Harkins
2012-04-26 11:15 ` Sebastien Vauban
2012-04-25 13:15 ` Eric Fraga
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).