"Felipe Csaszar" <[EMAIL PROTECTED]> writes:
> IMHO, the <slide> tag is not ideal. What happens is that while you are
> drafting a presentation many times you don't know if something is
> going to be a bullet, a slide, or even a section, so it is very useful
> to have a lean wiki notation to make changes swiftly. On the other
> hand, a <note> tag is useful. First, not everybody uses notes, and
> second, once something starts as a note it will probably stay there.
Hmm, I suggest that you may be over-generalizing from what you yourself
would like to see in a slides style. One would need to think about what
other people might want to use it for too. I do agree that the notation
should be as "lean" as possible.
As I said earlier, I think the basic design question is: should
slides or notes be at the top-level?
[Actually, "notes", isn't quite the right word, since what beamer calls
notes are notes for the person giving the talk. I envisaged a <note>
tag for those, so we need a name for non-frame non-note text; I'll call
it "body text" here. Another terminological point: beamer uses the word
"frame" for what I call "slide" here.]
One way to accommodate different use patterns would be to use a
directive to make it optional whether slides or body text sections are
top-level in a particular document, so you could have
#slides-top-level
* Basics
- First slide
- First bullet
- sub bullet
- Second bullet
<body>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Cras
hendrerit, metus quis porta tempus, velit turpis semper leo, vitae
porttitor felis augue ut risus.
</body>
- Second slide
1. numbered item
2. numbered item
or
#body-top-level
* Basics
<slide>
- First slide
- First bullet
- sub bullet
- Second bullet
</slide>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Cras
hendrerit, metus quis porta tempus, velit turpis semper leo, vitae
porttitor felis augue ut risus.
<slide>
- Second slide
1. numbered item
2. numbered item
</slide>
One of these could be customizable as the default method.
It would be easy enough to flip one or the other of these in the
pre-processing stage of publishing [for example: </note> -> <slide>,
</slide> -> <note>].
Although I have used it in the above examples, I am not sure that I like
the idea of using top-level itemize items to announce a new slide. It
seems to me that it makes a special case of those list items that would
be confusing, and not at all flexible. It would also not reflect the way
that slides are rendered by the beamerarticle package: where they appear
to resemble unnumbered subsubsections. Also, what would a slide with no
title look like?
One idea I had is to use something like @ characters as markup for slide
headings. In beamer, section headings and slide titles and subtitles
are sort of orthogonal to each other, so one couldn't simply use the
usual * markup. Something like this:
* Basics
<slide>
@ First Slide
@@ First Slide Subheading
- First bullet
- sub bullet
- Second bullet
</slide>
[and the same for the option with slides as top-level]
> Some of the programming difficulties I see are things which (I
> believe) are not easy to accommodate with the current muse
> architecture. I see the following constructs more or less problematic:
> - The || to start a new column
> - All the special includes for eps, latex+eps, verbatims, and what I
> call 'chunks' (complex structures like tables that can be put at the
> end of the file, so that they do not bother with the presentation
> outline).
> - The ! to animate
> - The # for numbering (note manual numbering: 1. 2. 3. ... is not
> ideal as the user has to change numbers when reshuffling a list)
I think all of these are feasible, apart for the numbering of lists,
which is not necessary.
I don't know if I like the "chunks" feature, though: it seems to me to
move the information away from its context, but that could be
incorporated as well.
The trickiest one to my mind is the new column markup, since one would
have to allow for tables in slides.
Regards,
--
Jim Ottaway
_______________________________________________
Muse-el-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/muse-el-discuss
