$Date: 2002/02/20 13:50:14 $
svgSlidemakeron Windows without cygwin
The goal of the
svgSlidemaker tools is to make it easy to generate a
presentation slide set in SVG, with one SVG file per slide. The individual slides are linked,
have a common look and feel including a logo, the name of the presenter, etc.
svgSlidemaker is not an authoring tool to create, eg, fancy figures for
the slides. Instead,
svgSlidemaker relies on a "pool" of slide content files
created by the user previously; the tool integrates those in a coherent slide set.
As far as
svgSlidemaker is concerned, the content "pool" may contain two type
svgSlidemaker takes these files from the pool, "embeds" each of them into a
larger SVG slide file containing a header, a footer, and link arrows to generate a series of
SVG slides. Because the original SVG files are copied, the resulting set of slides can be
treated separately, archived, put on a web site, etc.
To generate a specific presentation, the author has to create an XML file called
directory.xml, whose exact format is described below. This
file includes the necessary information for each individual slide (title, content file URI,
etc), as well as information concerning the full presentation (author, date, logo, etc).
svgSlidemaker processes this file to generate the final slide set.
svgSlidemaker works optimally either on UNIX or on Windows running
cygwin; it makes use of the
make facility. Some provision have been
done to use it on Windows without
cygwin, but not all features are available for
those systems (see Appendix II for further details).
svgSlidemaker is based on XSLT. However, the XSLT recommendation does not
specify the calling sequence of an XSLT processor, nor does the current version include a
facility to control the redirection of the output of the processor (ie, to generate several
files using the processor and the same source XML file). (XSLT 2.0 will standardize this
facility through the
xsl:result-document function.) As a consequence,
svgSlidemaker works with two specific XSLT processors only, namely Saxon[saxon] and Xalan[xalan]. The user has to choose
between the two by using the appropriate Make files.
Note that, at this moment, the binary distribution of
xalandoes not include the necessary
Redirectextension, in spite of its on-line documentation. Users have to install
xalanthemselves using the Java sources. Hopefully, this problem will disappear in future.
In what follows, the usage of
svgSlidemaker will be
described separately from its implementation. Although it is good to know
how the tool is implemented in case problems occur, separating the two aspects makes it easier
to get familiarized with the tool.
A general presentation on W3C, held in December 2001, is available on-line, and shows a typical
example for a slide set generated by
Note: although the documentation below uses an XML Schema formalism, correctness of the schema definition in the text has sometimes been sacrificed for a better readability of the documentation. The distribution contains the proper XML Schema files.
Generating a slide set with
svgSlidemaker is done through the following
maketo generate the complete slide set
It should be emphasized that this tool does not help in the second step!
The distribution includes two standard make files, one for
MakefileXalan) and one for
file should be copied into the directory where the tool will be used. The local variable
SMHOME (at the top of the make file) gives the path to the directory where the
svgSlidemaker resides; this has to be updated.
The makefile provides the following make targets:
directory.xmlfile changes, all slides will be regenerated. This is the default target.
svgSlidemakergenerates a number of intermediate files (see the implementation for more details); this action remove them all and leaves the generated slide files intact. This action is typically used before publishing the slides on the web.
The slides generated by
svgSlidemaker make use of CSS style sheet files. The
distribution contains two of those:
the slide content and the background, respectively. A finer control over which CSS files are
used is possible through the
directory.xml file, see the description below.
As described in the introduction, the content of the slide can be either an SVG file or a simple XML file for an essentially textual content.
Unfortunately, the limitations of the tools (and of the author...) used to implement
svgSlidemaker impose some light restrictions on the SVG files. None of these are
serious, though. These limitation are as follows.
svgelement should be:
<svg xmlns:xlink="http://www.w3.org/1999/xlink" ... >
SVG players have no problem with this (superfluous) declaration, so the SVG file itself can be used elsewhere, too.
viewBoxattribute of the outermost
svgelement. The possible
heightattributes are ignored. In other words, the presence of the proper
viewBoxattribute is mandatory.
Because a large percentage of presentation slides consist of a list of text items only
(bulleted or not), a separate XML application has been defined to create such slides. Such
"standard" slides may also include an image, positioned to the left, right, top, or bottom, with
the textual content filling the other "half". A more detailed description of these standard slides is available in a separate
svgSlidemaker tool recognizes those files and incorporates them
into the final slide set. For the sake of this documentation, we will refer to this XML
application as "SDS".
The model described in the previous section is based on a collection of independent SDS
files. It is also possible to collect a number of SDS slide contents into one file; see the
documentation of for the details. Suffices it say at this
stage that the file includes a sequence of standard contents, which can be referred to though
The structure of the full presentation is governed by a separate XML file, called
directory.xml. This file is, essentially, a collection of
elements (one for each slide), preceded by some global elements referring to the slide set as a
whole. (A separate XML Schema has been defined for the file with
a detailed documentation ).
The top level element is
slides; its (simplified) schema definition is:
<xsd:element name="slides"> <xsd:sequence> <xsd:all> <xsd:element name="author" type="xsd:string"/> <xsd:element name="URL" type="xsd:anyURI"/> <xsd:element name="title" type="xsd:string"/> <xsd:element name="date" type="xsd:string"/> <xsd:element name="origin" type="xsd:anyURI"/> <xsd:element name="textOrigin" type="xsd:anyURI" minOccurs="0"/> <xsd:element name="css" type="xsd:anyURI" minOccurs="0"/> <xsd:element name="backgroundCss" type="xsd:anyURI" minOccurs="0"/> <xsd:element name="backgroundPattern" type="xsd:anyURI" minOccurs="0"/> <xsd:element name="URIReplacement" minOccurs="0"/> <xsd:element name="logo" type="xsd:anyURI" minOccurs="0"/> <xsd:element name="rasterizer" type="xsd:string" minOccurs="0"/> <xsd:element name="page" type="xsd:string" minOccurs="0"/> </xsd:all> <xsd:element name="slide" maxOccurs="unbounded"> </xsd:sequence> <xsd:attribute name="compress" type="xsd:boolean" use="optional" default="false"/> </xsd:element>
(All elements in the
xsd:all portion can appear maximally once, in any order.
The first five elements should appear exactly once.)
true, the tool creates two parallel slide sets: one compressed and one un-compressed. (If the slides are published on the Web, it is advisable to put both versions on a web site; older browsers may have problems with decompression on the fly.) Default value is
<xsd:element name="author" type="xsd:string"/>
The author of the presentation. The name will be put into the lower left hand corner of every slide.
<xsd:element name="URI" type="xsd:anyURI"/>
If the value is non-empty, the author field on the slide will be a hyperlink with this URI. Typically used as a "mailto" URL.
<xsd:element name="title" type="xsd:string"/>
The title of the full presentation.
<xsd:element name="date" type="xsd:string"/>
The date of the presentation. Will appear on the lower right hand corner of every slide.
<xsd:element name="origin" type="xsd:string"/>
A path to the directory where the SVG files of the "pool" are. This can be overwritten for an individual slide, this element merely specifies the default value.
<xsd:element name="textOrigin" type="xsd:string"/>
A path to the directory where the SDS files of the "pool" are. This can be overwritten for
an individual slide, this element merely specifies the default value. If this value is not set,
the value of
origin will be used.
<xsd:element name="css" type="xsd:string"/>
Name of the CSS file used for the content of the slide.
<xsd:element name="backgroundCss" type="xsd:string"/>
The background and some other stylistic elements of the slides (eg, font used for a title)
are controlled by a separate CSS file. By default, the file's name is
background.css, but this can be overridden by this attribute. The necessary
classes are specified in a separate section below.
The distribution includes a
background.css file that can be used as an
<xsd:element name="backgroundPattern" type="xsd:anyURI"> <xsd:attribute name="width" type="xsd:integer" use="required"/> <xsd:attribute name="height" type="xsd:integer" use="required"/> </xsd:element>
This element offers an alternative to styling in controlling
the general outlook of the slides.
backgroundPattern refers to an arbitrary image
which is duplicated both in X and Y direction on the background (using SVG's pattern fill
facility). When using a background pattern, the class definitions for the background rectangle
become ineffective; nevertheless, the various classes controlling,
eg, the title fonts are still used.
<xsd:element name="URIReplacement"> <xsd:attribute name="from" type="xsd:string" use="required"/> <xsd:attribute name="to" type="xsd:string" use="required"/> </xsd:element>
The original SVG content might use elements with hyperlinks using relative URI-s. Because
the content is copied to another directory, these URI-s become invalid. The
URIReplacement element defines a replacement pattern for the starting portion of
each relative URI in the SVG code. Eg, if the
from is set to
../../ABC/DEF/ then the
../../ portion of
all relative URI-s will be replaced by the value of
URIReplacement element can also be overruled locally for a specific
<xsd:element name="logo" type="xsd:anyURI"> <xsd:attribute name="width" type="xsd:positiveInteger" use="required"/> <xsd:attribute name="height" type="xsd:positiveInteger" use="required"/> <xsd:attribute name="w3c" type="xsd:boolean" default="false"/> <xsd:attribute name="href" type="xsd:anyURI"/> </xsd:element>
By default, the generated SVG slides have an embedded W3C logo on the upper left hand
corner. This can be overruled by the
logo element. The content of the element is
considered to be the name of an image, and the
image element of SVG will be
embedded onto the final slide (using the width and height values). Note that, in SVG, the
image element can also refer to an external SVG file. One can also require to keep
the original W3C logo on the slide (adjacent to the new logo) by setting the
true; this is useful if the slide set has been prepared in
cooperation with somebody outside of W3C. Finally, the logo can be an active link or not,
depending on the setting of the
<xsd:element name="rasterizer" type="xsd:string"> <xsd:attribute name="width" type="xsd:positiveInteger" use="required"/> <xsd:attribute name="height" type="xsd:positiveInteger" use="required"/> </xsd:element>
This attribute controls the printing/HTML generation facility, described separately below.
<xsd:element name="page" type="xsd:string"> <xsd:attribute name="orientation" type="xsd:string" use="required" default="landscape"/> </xsd:element>
This attribute controls the printing/HTML generation facility, described separately below.
<xsd:element name="slide"> <xsd:sequence> <xsd:all> <xsd:element name="title" type="xsd:string"/> <xsd:element name="tooltip" type="xsd:string"/> <xsd:element name="file" type="xsd:string"/> <xsd:element name="origin" type="xsd:string" minOccurs="0"/> <xsd:element name="css" type="xsd:anyURI" minOccurs="0"/> <xsd:element name="backgroundCss" type="xsd:anyURI" minOccurs="0"/> <xsd:element name="URIReplacement" type="URIReplacmentType" minOccurs="0"/> </xsd:all> <xsd:any namespace="http://www.w3.org/2001/svgSlidemaker/textSlide" processContents="lax" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="text" type="xsd:boolean"/> </xsd:element>
(The elements in the
xsd:all can appear in any order; the first three should
appear exactly once.)
true, the slide refers to a SDS file, otherwise it refers to SVG. The default value is
This element describes the content of an individual slide. The
URIReplacement elements are
analogous to their global counterparts, except that they are valid for that specific slide
only. Note that putting an empty
css element is a way of overruling the general
css element without generating any CSS reference whatsoever.
<xsd:element name="title" type="xsd:string"/>
The title appears on the top part of the slide.
<xsd:element name="tooltip" type="xsd:string"/>
The tooltip is used when the mouse rolls over the arrows linking the slides.
<xsd:element name="file" type="xsd:string"> <xsd:attribute name="id" type="xsd:ID" use="optional"/> </xsd:element>
The basename of the file. It is important to note that this name should not be a
path, nor should it include the file extension; the same name will be reused to generate
intermediate files. The full path of a file will be the concatenation of the value of
file, followed by either
xml, depending on whether the slide is based on an SVG or an
<xsd:any namespace="http://www.w3.org/2001/svgSlidemaker/textSlide" processContents="lax" minOccurs="0"/>
Although the conceptual "model" of
svgSlidemaker is that SDS files are stored
in separate files, it can be sometimes disagreeable to have to create and manage individual
files for a few lines only. Using a proper namespace it is possible to include an SDS content
directory.xml directly. The value of
file is still used for the
naming of intermediate files. See the Appendix I for the usage of this
The background of each slide is composed of three rectangles, using the CSS classes slideBackground, titleBackground, and signatureBackground. The latter two are simple rectangles whose color can be set using the appropriate style sheet statements in the background style sheet file.
slideBackground is slightly more complex insofar as it is filled by a
linear gradient fill from left to right, setting stops at 3% of the background rectangle on the
left and on the right, respectively. Classes are also assigned to the stops. This means that
the background color is controlled by three more style sheet statements in the background style
sheet file: stop.side, stop.side-right,
and stop.middle. Setting the color for these classes will set the
color on the left, the right, and the middle part of the slide, respectively. Assigning the
same color to all three of them yields a uniform background. Remember, though, that if a background pattern is also defined, the rectangle with
slideBackground is not drawn, ie, these class settings become
ineffective! (The rectangle is replaced by the patterned background.)
The rectangles for the title and the signature areas are drawn on top of the slide
background rectangle. If the author wants to have the same, uniform color (or gradient fill)
for the full slide, the solution is to set both the stroke and fill to
both of these classes.
Here is the complete list of classes, which are used by the slides:
The current SVG browsers do not offer reliable facilities to print SVG files.
svgSlidemaker offers a suboptimal solution to get around the problem (hopefully,
this facility will become obsolete in future). One can generate a PNG image for each slide, use
an XHTML page to collect, through a series of
img elements, all images in one
file. This XHTML file can then be printed like any other XHTML page. CSS statements in the file
make it sure that each slide is printed on a separate page.
As a "by-product", this file can also be used as a "poor man's presentation facility", if no SVG player is present. CSS statements are used for a presentation media (although very few browsers implement it yet).
Generation of images requires an external program to "rasterize" an SVG file. At this moment, only batik[batik] can do that properly, and the slidemaker tool relies on the availability and proper installation of batik in this respect.
The control over the generation can be done by the
rasterizer element content is used as
the command line to start up the rasterizer on the local environment; the
height control the size of the generated images. The generated XHTML file
The default values for
svgRasterizer.batfor the command;
Care should be taken if these values are changed:
cygwin, it is not always possible to start up batik directly, only via a '.bat' file (there is a clash between the slash and the backslash...). That is why a separate '.bat' is used.††
By default, the setup generates an XHTML file to be printed in landscape mode, yielding one
slide per page. By setting the
orientation attribute of the
page element to
portrait, the PNG files and the
XHTML file will be generated for portrait mode printing, with two images per page (one above
The images and the
Slide.html files are generated using the
html command. (Beware! Rasterizing the SVG slides quite a long process.)
svgSlidemaker uses XSLT transformations to produce the slide set in several
directory.xmlis used to generate a separate table of content SVG file, called
directoryslide.svg. This is a convenience file to the presenter: it is a table with a link to all the slides. Both the pure SVG and the compressed version of the same file are generated by the
directorySlide.xslfile. (Each generated slide has a link to the table of content: the small animated circle between the forward and backward arrows.)
extractTextfiles.xslis used to extract the embedded SDS content from
directory.xml. A separate SDS file is created for each of those.
slides.xslgenerates a separate XSLT file for each slide. The generated XSLT files differ from one another in terms of the tooltips, links, title, etc, they use, but their overall structure is, obviously, analogous.
makefile.xslgenerates a makefile (called
MakefileSlides.mf) adapted to the slide set, with one target per slide.
The first pass is controlled by the
Makefile in the distribution;
make is then recursively called using the generated
MakefileSlides.mf, each slide is generated separately using the slide-specific XSLT file. This may be preceded by a separate step, using
textSlide.xsl, to generate an intermediate SVG file using an SDS file. The SVG file is embedded in the middle of the slide by keeping the
svgelement and its content verbatim, but by surrounding it with all the other goodies (signature, links, title, etc).
Slides.html, used for printing, is generated by a separate
Due to the structure of the make files, a re-run of
make runs the necessary
XSLT process only for the slides whose content has changed. Saxon is not very fast, so this may
come handy when the slide set is large.
The image below gives a rough overview of the main steps, omitting the extra processing needed by the SDS contents:
An initial attempt to develop an RDF vocabulary to annotate SVG files has been described in
a separate document.
takes this vocabulary, and the related tools, into account as follows:
titleelement is generated into each of the slides, making use of the title specified in the
directory.xmlfile (plus the sequence number of the slide).
metadatasection exists in the enclosed SVG file, this is "moved" to the top level.
<slides compress="true"> <author>Ivan Herman (firstname.lastname@example.org), Head of Offices</author> <URI>mailto:email@example.com</URI> <title>Test presentation</title> <date>Amsterdam, 01.11.2001</date> <origin>../exampleAssets/</origin> <css>../slide.css</css> <URIReplacement from="../" to="../../../Consortium/Offices/Presentations/"/> <backgroundPattern width="100" height="100">patt.jpg</backgroundPattern> <!-- optional --> <rasterizer width="950" height="649">svgRasterizer.bat</rasterizer> <!-- optional --> <page orientation="portrait"/> <!-- optional --> <slide> <title>RDF Reification</title> <tooltip>RDF</tooltip> <file>RDFReification</file> </slide> <slide> <title>Animals</title> <tooltip>Animals</tooltip> <file>animals</file> </slide> <slide> <title>P3P</title> <tooltip>P3P Architecture</tooltip> <file>p3p2slide</file> <origin>./</origin> </slide> <slide text="true"> <title>Text Only Slide</title> <tooltip>Text Only</tooltip> <file>text</file> <origin>./</origin> </slide> <slide text="true"> <title>Further Information</title> <tooltip>Information</tooltip> <file>Information</file> <s:slide xmlns:s="http://www.w3.org/2001/svgSlidemaker/textSlide"> <dt>More information about W3C:</dt> <dd href="http://www.w3.org/Consortium/">http://www.w3.org/Consortium/</dd> <dt>Local W3C offices:</dt> <dd href="http://www.w3.org/Consortium/Offices/">http://www.w3.org/Consortium/Offices/</dd> <dt>Contact information:</dt> <dd href="http://www.w3.org/Consortium/Contact">http://www.w3.org/Consortium/Contact</dd> <dt>W3C home page:</dt> <dd href="http://www.w3.org">http://www.w3.org</dd> <dt>These slides are at:</dt> <dd href="http://www.w3.org/2001/Talks/IH-2211Mechelen/">http://www.w3.org/2001/Talks/IH-2211Mechelen/</dd> </s:slide> </slide> </slides>
svgSlidemakeron Windows without cygwin
Yet another XSLT script (
createCommands.xsl) is available to generate a Windows
command file to call saxon for each of the generated slides. The
make.bat is a
simple batch file, which has then to be invoked from within the directory where the slides are
createCommands.xslto generate the separate batch file (
slides.batto generate all files.
The disadvantage is that there is no control over the versions and all slides are regenerated every time.
Some features have not (yet) been implemented for the Windows version
createxslbat.xslversion has been discontinued. This XSLT stylesheet included three functions in one (generation of the command files, the
directoryslide.svgand the separate slide-specific stylesheets), which made it quite difficult to maintain properly. The functionalities have been "cut" into separate stylesheets. This made it possible to have different version of the generated command files, too.
hrefattribute is added to TS.
spanelement for TS.
URIfor the element names in the TS files. Beware: older directory description files may have to be adapted.
slideelement to appear in any order.
aelement to TS.
system-propertyfunction. The separate note has become superfluous and has been removed.
† Care should be taken to use version 6.2.2 or higher; earlier versions had a bug which created difficulties for the slide maker tool. Windows users can also download a precompiled code, called instant saxon. For convenience, the Windows executable for instant saxon is part of the downloadable gzipped tar file.
†† The '.bat. file is
quite simple, actually; it contains one single line of the form:
java -jar C:\Bin\batik-1.1\batik-rasterizer.jar %1 %2 %3 %4 %5 %6 %7 %8 %9
one just has to change the path.