On 24/09/10 00:36, Phillip Lord wrote:
Stuart Rackham<[email protected]> writes:
So far, I have basic slidy working, producing a presentation. It uses
the asciidoc style sheets, so you get slides that look like asciidoc. It
has an integrated copy of slidy.js and slidy.css, and if you set the -a
data-uri option, then you get an all-in-one HTML file (this required
one small change to slidy.js, unfortunately).
That works well Phil, I like being able to generate a self contained single
document slideshow.
Yes, this is a big advantage. It makes a slidy.html much more powerpoint
like. You can pass it around.
I made a few changes to your slidy.conf (diff and example attached):
- Allow the incremental feature to be specified on numbered lists and on
blocks grouped in 'Openblock's using the 'role' attribute.
Okay.
- Explicitly specify slides with an Exampleblock 'slide' style (I commented
out the implicit document title/author output in the header).
Unfortunately, this runs counter to my main use case. I want to plug
into existing documents. The reason for this is that I am using
asciidoc's multiple output. The idea is that I can generate printed
handouts (through docbook and pdf), as well as a non-slidy HTML
versions, which is easier to read. Asciidoc is good for this, because I
have conditionals; the versions are similar, but not identical.
I can send you a sample if you want to see what I mean; I don't want
them public and googlable for the next week or so, otherwise, they would
be public!
You can use the AsciiDoc 'Openblock' to group arbitrary block elements for
incremental display.
Okay, that is useful, although it still has the problem that *any*
markup will be incremental. So
** First item
** Second _item_
** Third item
will produce 4 increments.
What was the "## Restore source highlighting" at the end of
slidy.conf" stuff for?
In my hands, the source highlighting didn't work. The problem is that
the source code filter has stuff like this....
ifdef::backend-xhtml11[]
ifndef::pygments[source-style=template="source-highlight-block",presubs=(),postsubs=("callouts",),posattrs=("style","language","src_numbered","src_tab"),filter="source-highlight
-f xhtml -s {language} {src_numbered?--line-number}
{src_tab?--tab={src_tab}}"]
ifdef::pygments[source-style=template="source-highlight-block",presubs=(),postsubs=("callouts",),posattrs=("style","language","src_numbered"),filter="pygmentize
-f html -l {language} {src_numbered?-O linenos=table}"]
endif::backend-xhtml11[]
which fails because the backend is now slidy. I had the same problem
with source highlighting in wordpress.conf, if I remember. My code is
just a cut-and-paste job from the source-code conf file.
Ugly, but quick. I should have refactored source-code.conf, but when I
started slidy.conf it was outside of asciidoc clone, so it was the
easiest solution.
Putting this in slidy.conf will ensure all filter code intended for xhtml11 will
be rendered in the slidy backend:
[attributes]
# Slidy is XHTML, based on xhtml11 so we want the xhtml11 filter sources.
backend-xhtml11=
Cheers, Stuart
Phil
--
You received this message because you are subscribed to the Google Groups
"asciidoc" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/asciidoc?hl=en.
