This is a slidemaker tool. The fundamental goal is to use one input file, written in XHTML (with some restrictions) and generate, eg, a series of XHTML and/or SVG files, one file per slide and with the appropriate links, or an input file used by a special PHP script (the latter is, essentially, a script produced by Dean Jackson, with some very minor modifications).
In the input file each slide is surrounded by a div of class "slide"; the only h1
element within a div serves as a title of the slide.
The tool is a set of Python modules. At present, it consist of a general core, and subclasses to generate a series of XHTML slides or a series of SVG slides. Adding subclasses to generate one large SVG file, VoiceXML, or other formats becomes relatively straightforward (it mainly requires a familiarity with the target format, as well as some programming practice in Python). To run the scripts the PyXML module must be installed, too.
The module includes a Python script (slidemaker.py) that can serve as command line
call. The module can be invoked with the following options:
all.html)Just for usual unix programs, options can be combined. Ie, slidemaker.py -szhv means
to generate compressed SVG files as well as HTML files with '.html' suffixes, and print the
progression on the screen.
The following rules must be followed in all cases:
<div class="slide"><div class="slide">) may begin by a h1
and this must be the only usage of h1-sobject statementThe SVG files themselves should not set their dimensions explicitly, but should use the
viewBox attribute instead. This ensures a proper re-scaling of the content.
If the intention is to use SVG slides on the output, there are some further restrictions. Essentially, the format is XHTML Basic, but with some further (maybe temporary) restrictions:
base and form modulesbr, address elements.colgroup, rowspan), etc, are
implemented. The rows and the table cells are evenly spread in the available horizontal space, that
is about it. The position of each cell content is set to the start of the cell position; for header
cells the position is set to the middle (style sheet control may ensure to use that position as the
right anchor). There is a limited implementation of caption, the border and background
attributes for table cells. value or start attributes for li elements are understood
when part of an ol. Note that, in contrast to XHTML Basic, the numbering does not rely on CSS,
simply because almost no CSS implementations implement this feature yet, so the author will have to use
these deprecated attributes.list-style-type (or, at a lower priority, the list-type) CSS properties
are understood when part of a style attribute (the script does not do a full CSS processing to associate
CSS properties to elements). For numbered list, the roman, alpha, decimal, and greek numberings can be
used; for un-numbered list, the styles disc, square, circle, and
none are interpreted (note, however, that the Unicode characters used for these styles may not
be available for all fonts!).style element is also understoodstyle element, except when
interpreted by the conversion (eg, list type, floating).For the XHTML and SVG cases, the output of the tool is a series of XX.html or XX.svg(z) files, respectively,
where XX stands for the number of the slide. Furthermore, an Overview.html (resp.
Overview.svg(z)) file is generated with links to the individual slide in the form of a
table of content. For the Overview.html file the Table of Content may be preceded by a separate text: if the input
file contains a separate div of class 'prologue', that portion will be copied verbatim to the
beginning of Overview.html.
For the PHP case, the output is a single file called slides.html, and a PHP script called Slides.php. An Overview.html is generated but only with the possible prologue content.
Note that the file names for the Overview, Slides.php, etc, can be modified by key/value pairs, see below.
Slides may have illustration in two different formats: images (in png, jpg, etc) or include SVG content.
Traditional images are set using the img element. The generated HTML slides uses that
verbatim. Generated SVG slides use SVG's image element to access the image.
In the case of SVG the size of the image is important. For that purpose, using the width and
height attributes in the img
with percentage values is the most appropriate; the tool uses these
percentage values against the content area to position the image. If
not set as percentages, the values are taken over verbatim (but that
might become a problem on the generated slide...)
A future extention of the tool might interpret the image and extract the size from the image and position it on the page accordingly. Note that this would require the installation of a separate image handling library in Python (called PIL), not part of the default distribution and not that easy to distribute because it is a binary program not a python script...
SVG content must be set through object elements (the mime type
must be set to image/svg+xml). The tool interprets the element, albeit using
very different approaches for the HTML/PHP and SVG cases.
For HTML/PHP slides, the tool replaces the SVG content with reference to an image, following the algorithm:
object element gives an alternative image as its child, this will be copied
into the generated slide verbatimobject will get the 'png'
suffix and that will be used as an image reference (see also the image property
below that might be used to set the directory for the image, instead of using the directory of the 'data' value.By default, the SVG file in the 'data' attribute will be copied into the target SVG slide. However, if the 'data' URI contains a fragment identifier, too, than only an external reference to that URI will be added to the SVG file, without copying the content.
The source file may also use an object element to refer to a MathML file (the mime
type in the object must be set to application/mathml+xml). For XHTML output,
the content is copied into the target slide, enclosed in a math element with the proper namespace.
(SVG slides ignore the MathML object, there is no automatic conversion to image yet).
The generated XHTML file also includes the mathml.xsl XSLT style sheet, and some other
attributes are set, as described on the "Putting mathematics on the Web with MathML page. Note that the files must be served as XML to be properly displayed on a Mozilla
browser, for example.
The fundamental tool to customize the output is CSS (both for HTML and SVG). The distribution contains a number of style combination. The basic mechanism for the customization of SVG slides is to use the pattern filling feature to control, eg, the background of a slide. This is done by defining the patterns once and for all in a separate SVG file and refer to it through a CSS file (this is the mechanism that does not work in the ASV3 version, though…)
Beyond what CSS can do, there are a number of features of the tool that can be controlled via key/value pairs. The accepted values of key/value pairs are listed below. These key/value pairs can be set in various files, defining site-wide defaults as well as the flexibility for defaults in the presentation. The places where the key/value pairs can be set are (in increasing priority)
SlidesDefaults.py for all, HTML.HTMLDefaults.py and SVG.SVGDefaults.py
for HTML/PHP and SVG, respectively. These are in the format of Python dictionaries, and are typically set for the whole siteDefaults.py file (containing a dictionary with the name of Defaults)
in the same directory as in a CSS style file in the header of the input
file, that is imported. Eg, if the input file contains:<link href="Style/style.css" type="text/css" rel="stylesheet" />
and the directory Style contains the file Defaults.py, that is imported.meta variables in the header part of the intput fileobject) might include the property pair
using the attribute with the keys in the http://www.w3.org/Consortium/Offices/Presentation/xsltSlidemaker
namespaceThe various key/value pairs are listed below.
Note that these attributes are also used to add metadata to the generated slides, for example in RDF format in the SVG files.
Some of these attributes are used to control the visual output of the SVG slides, primarily coordinate values. At the moment, such customization cannot be done in CSS. These should typically be set in a general Python modules rather than in the input files.
pre elements of the input).
class set to ObjectBackground)
should be generated as a background for included images. This can be
used, eg, to give another background colour via CSS styleing.
The value must be True or False.
link
statements, add the 'SVG' to the basename, and use that as a basename for the references SVG file.
This property can be overriden by giving an explicity reference to a CSS file name.
This property might become unnecessary in future. The current ASV implementation has some bugs in the way CSS files are referenced; in a new version this might be settled and then the default mechanism might be quite enough.
The script interprets the lang attribute, if set on the html element: it sets the
appropriate lang xml:lang attributes on the XHTML and SVG files. If not set, the
language setting is en.
By default both SVG and XHTML files are utf-8 encoded. For SVG slides, this is not a problem (most servers are set up so that SVG files are served as XML files with utf-8), it might be a slight problem for XHTML files. For XHTML, the server should be set up to serve the XHTML file in UTF-8, see the document provided by W3C's I18N Activity, for example.
A sequence of div-s for slides can be enclosed in a div with class `chapter'. The first
h1 element in the chapter sets the chapter title; this will be displayed on all slides
in the chapter as part of the header. (Though it can be controlled by CSS, the chapter title usually
appears on top of the slide title with small font.)
A slide (i.e., a div of class 'slide') may be empty but have instead an extra href
attribute in the http://www.w3.org/Consortium/Offices/Presentation/xsltSlidemaker
namespace. The value of this attribute (typically a URI with fragment identifier) should identify a similar
div in another file; that div (i.e., the corresponding slide) is copied into the
to replace the empty div.
If the input file includes an a element with a fragment identifier URI (i.e., only
of the form href="#something", the fragment identifier is supposed to match an "id" attribute
of one of the slide div elements. In the generated HTML, PHP, and/or SVG slides, the link is
replaced by a link to the corresponding file. This is handy to make cross references among slides...
Everything is in a compressed tar file. Unfortunately, the current setup is a bit clumsy due to a bug in the current ASV6 implementation (they mess up the base URI for an included CSS file); as soon as they come out with a proper version, I plan to do a proper Python installation setup.
Copyright © 1994-2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.