Kontrawize author Anthony Coates warns that this is an attractive time sink. Thanks for the heads up.
My first round of research found HTML Slidy , but didn't find DocUtils + S5 . S5 is simpler and does less than Slidy. RST markup is far easier to cope with than HTML. This looks like a powerful and simple solution.
Indeed, a LEO outline which produces RST directly (via an @file directive) for use by rst2s5.py is a piece of cake. Similarly, a small change to rst2s5.py could create an rst2slidy.py, also.
Better Integration
The next step, however, is more subtle. We have a number of choices of integration between DocUtils, S5 and Leo. These choices stem directly from two prominent features of this technology stack:
- This is all open source. We can integrate at a number of levels: the application level, using the defined file interfaces, or the module level, directly marrying DocUtils into Leo.
- This is all Python. Integration doesn't involve too much more than an appropriate import.
There are a mountain of alternatives:
- Leo's RST3 plug-in can produce HTML. It would be nice to make rst2s5.py unnecessary, since the DocUtils parsing is already embedded in Leo. However, RST3 would have to produce <div class="slide"> in addition to <h1> tags.
- A variant on the RST3 plug-in that produces HTML more directly focused on S5's .js and .css. This could produce the required <div> tags.
- A simple plug-in that produces a pure RST text file, transforming headlines into RST section headers. This could be run through rst2s5.py, leading to a tidy way to produce slides from an outline.
- Either of the two plug-ins could be designed to use HTML markup instead of RST. This would be slightly simpler in one sense (eliminating RST), but less usable.
- A simple @file directive which produces an RST file that is post-processed by rst2s5.py. This is doubly wasteful. First, the RST3 plug-in integrates DocUtils; why use an external application? Secondly, this requires the bodies be forced to match the headlines, wasting the headline information.
- A simple @file directive which produces an HTML file, directly focused on S5. This requires that the content be entirely in the bodies, making the headlines unimportant. This is wasteful.
And we haven't -- really -- scratched the surface. There are indirect integration using XML and XSLT that add complexity without demonstrable value.
- Since the Leo outline is XML, we can always fabricate some XSLT to transform the Leo outline into an S5-compatible HTML document.
- Worse, we can have Leo produce an XML/OML which is independent of S5/Slidy/PowerPoint or other approach, and write XSLT transformations from generic OML to S5 HTML.
What's wrong with XML-XSLT? It ignores the deep, open integration we can achieve between Leo, DocUtils, PythonPoint (and Bruce/pyGame if we went that route). XSLT puts the focus on the superficial integration available via XML representation of the underlying objects. A needless level of indirection in the open source world.
Making the Choice
What makes the most sense? The choice has to be consistent with the advice to build as little as possible. More important, the choice has to be consistent with the problem (replacing powerpoint) and the actual use cases.
- Edit the material. Hence Leo: it's fun to use an outliner to build presentations.
- Present the material. Adobe Reader, Opera-Firefox-whatever, or Bruce are all alternatives to make my laptop drive a projector.
- Distribute the material. This is a poser. Share the Leo file? Or share the resulting PDF? Or share the resulting HTML + .js + .css files? S5 handles distro a little better than Slidy, because S5 expects local storage.
- Print hand-outs. Adobe Reader does a great job of this. Opera-Firefox can do this job, also. Bruce falls down on this count. I could (I suppose) use PIL to create printable versions of the pages or something. :-(
The above analysis makes a strong case for integrating PythonPoint into Leo, and creating a PDF from that. A distant second is DocUtils rst2s5.py.