I want to put a minimal amount in the first version. Sort of like a version 0.1. And I won't design any further until I have that functionality implemented.
I dub the presentation framework "Sambal", because just like with the spicy sauce, if you use enough of it people will get teary-eyed. (In a good way.) It is meant to interoperate heavily with Niobium, which see.
Here's what a presentation file will look like.
use Sambal;
text "Slide 1";
text "Slide $_" for 2, 3, 4;
text "On slide 5, there's some more text which will probably be broken up into lines.";
text "Note that text is formatted Markdownishly: *italic*, **bold**, `code`";
text q:to /EOT/;
This text, because it's indented
with four spaces, will be rendered
as fixed-width and with newlines in
the right places.
EOT
text q:to /EOT/;
This text, because it's *not* indented
will probably be broken up into lines
but the rendering engine determines where
the linebreaks will be.
EOT
slide {
text "We haven't needed `slide` before";
text "It's for grouping objects.";
text "These three texts will simply look like paragraphs on the same slide";
}
text "You could do paragraphs with double newlines as well.\n\nLike this.";
transition;
text "Whoa! Did you see that?";
text "End of presentation.\nThank you.";
And that's it. Run perl6 on it and it'll produce a PDF for you.
Questions?
A: It's just regular Perl 6. text and transition and slide are just subroutines, exported by default by the Sambal module. In effect they all push "event" objects to an event queue. The module also installs an END phaser, which reads through the event queue and renders slides from it.
A: It makes the previous slide transition smoothly into the next. In this case, the text from the previous slide will probably pan away to the left while the text from the next slide comes panning in from the right. Consider this the "default" transition. The motion is such that it starts at zero, accelerates, and then slows down towards the end.
It's almost like, the cool thing isn't that we can make the slides transition into each other with a special effect; the cool thing is that we can make them do so by just inserting transition; in the right place in the slides source. It feels very natural, and the event queue makes it work, makes the transition event hook onto its two surrounding slide events. This kind of "natural" feel is what I will be on the lookout for as I extend the framework.
A: The eternal problem with SVG and text is getting reliable information about the size of text. You can set the textLength property on a given piece of text, thus actively controlling how wide it will be. But accurately setting this property means being able to accurately calculate it in the first place. The SVG 1.1 specification has this value as
"The total sum of all of the advance values from rendering all of the characters within this element, including the advance value on the glyphs (horizontal or vertical), the effect of properties ‘kerning’, ‘letter-spacing’ and ‘word-spacing’ and adjustments due to attributes ‘dx’ and ‘dy’ on ‘tspan’ elements."
So that's what we have to do too. I don't think there's any way around this, since doing accurate animations comes down to knowing precisely where things are located and how big they are.
See [http://stackoverflow.com/questions/1636842/svg-text-element-width](this StackOverflow question) and this text.xml.svg.devel thread for some ideas on how to go about this.
Q: Will you introduce non-text graphical objects, and positioning, and gradual slide buildup, and font awesome integration, and...?
A: Yes, but not at first. I'd like to get the above working well first, and provide both a proof-of-concept and a solid foundation to build the rest on.