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
of files:
SVG files
simple XML files to generate mainly textual (eg, a "bulleted list") content, with
possibly an included image (the latter can be another SVG file, though!). For the sake or
readability, the exact format of these files is described in a separate document.
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 xalan does not
include the necessary Redirect extension, in spite of its on-line documentation.
Users have to install xalan themselves 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 svgSlidemaker.
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.
The distribution includes two standard make files, one for xalan
(MakefileXalan) and one for saxon (MakefileSaxon). The
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:
Slides
Generation of all the slides. Note that if the directory.xml file changes,
all slides will be regenerated. This is the default target.
clean
Clean all generated files. This will remove the slide files, too!
publish
svgSlidemaker generates 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.
html
generate the PNG images and an XHTML file for printing.
The slides generated by svgSlidemaker make use of CSS style sheet files. The
distribution contains two of those: slide.css and background.css for
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.
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.
Don't use DTD
The SVG file should not contain a DTD definition. (The reason is that, for reasons not
clear to the author, saxon cannot properly handle an XML file with a DTD definition in
it.)
Explicit namespace declaration for xlink
SVG makes use of XLink. The DTD of SVG includes the proper namespace declaration, ie, the
SVG file itself does not necessary have to include it. However, because a DTD reference
should not be present in the SVG file, an explicit namespace declaration is required in
this case, otherwise the XSLT processor generates an error. In other words, the (outer)
svg element 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.
Use viewBox
Technically, the SVG file will be embedded into a larger SVG file (ie, the slide). To
establish the right positioning of the content, the tool makes use of the
viewBox attribute of the outermost svg element. The possible
width and height attributes are ignored. In other words, the
presence of the proper viewBox attribute 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
document. The 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
an XML IDREF.
The structure of the full presentation is governed by a separate XML file, called
directory.xml. This file is, essentially, a collection of slide
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 ).
(All elements in the xsd:all portion can appear maximally once, in any order.
The first five elements should appear exactly once.)
Attribute:
compress = "true|false"
Some of the SVG slides may become quite large, and
it might be a good idea to store them in a gzipped format. If the value of this attribute is
set to 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 false
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.
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.
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
example.
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.
pattern at the start of relative URI-s to be changed
to = "<string>"
replacement string
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 ../../
and the to to ../../ABC/DEF/ then the ../../ portion of
all relative URI-s will be replaced by the value of ../../ABC/DEF/. The
global URIReplacement element can also be overruled locally for a specific
slide.
keep the W3C logo, adjacent to the new one, or not
href
If exists, the logo area is an active link with this URI
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 w3c
attribute to 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 href attribute.
(The elements in the xsd:all can appear in any order; the first three should
appear exactly once.)
Attribute:
text = "true|false"
if the value is true, the slide refers to a SDS file, otherwise it refers to
SVG. The default value is false.
This element describes the content of an individual slide. The origin,
css, backgroundCss, and 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.
The title element
<xsd:element name="title" type="xsd:string"/>
The title appears on the top part of the slide.
The tooltip element
<xsd:element name="tooltip" type="xsd:string"/>
The tooltip is used when the mouse rolls over the arrows linking the slides.
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
origin (or textOrigin) and file, followed by either
svg or xml, depending on whether the slide is based on an SVG or an
SDS file.
If the slide is an SDS slide and the file refers to a collected text content file as
described in the separate section, the value of the attribute chooses a
specific text portion within that file.
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
into 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
feature.
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.
The 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 none for
both of these classes.
Here is the complete list of classes, which are used by the slides:
stop.side, stop.side-right, stop.middle
the colors to be used for the gradient fill on the background of the slide. See the
explanation above
rect.titleBackground
the style of the rectangle covering the title area (logo, slide title, link arrows)
rect.signatureBackground
the style of the rectangle covering the bottom area (name, number of slides, date)
line.title
the style of the horizontal line separating the title area from the slide content
text.title
the style of the title text (in the middle of the title area)
text.authorDate
the style of the text at the bottom, for the author, date, number of slides
path.linkArrow, circle.linkArrow
the style link arrows in the top right corner
text.tooltip
the style of the tooltip text (appearing when the mouse is over the link arrow)
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 and page
elements of directory.xml. The rasterizer element content is used as
the command line to start up the rasterizer on the local environment; the width
and the height control the size of the generated images. The generated XHTML file
is Slides.html.
The default values for rasterizer are:
svgRasterizer.bat for the command;
950 (resp. 649) for the width (resp. height) values.
Care should be taken if these values are changed:
when using batik from 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.††
the default width and height values have been chosen to ensure a proper printout on an A4
paper in landscape mode with one slide per page. With larger values, parts of the images can
be cut off. For US Letter paper size, the figures should be adapted by hand...
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 other).
The images and the Slide.html files are generated using the make
html command. (Beware! Rasterizing the SVG slides quite a long process.)
svgSlidemaker uses XSLT transformations to produce the slide set in several
steps.
First pass:
First, a number of intermediate files are generated. These are as follows.
The directory.xml is 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.xsl
file. (Each generated slide has a link to the table of content: the small animated circle
between the forward and backward arrows.)
extractTextfiles.xsl is used to extract the embedded SDS content from
directory.xml. A separate SDS file is created for each of those.
slides.xsl generates 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.xsl generates 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 file.
Second pass:
By virtue or running make on 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 svg
element and its content verbatim, but by surrounding it with all the other goodies
(signature, links, title, etc).
The Slides.html, used for printing, is generated by a
separate html.xsl XSLT file.
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. svgSlidemaker
takes this vocabulary, and the related tools, into account as follows:
A proper title element is generated into each of the slides, making use of
the title specified in the directory.xml file (plus the sequence number of the
slide).
If a metadata section exists in the enclosed SVG file, this is "moved" to
the top level.
The tool for the SDS slides will generate the relevant RDF section automatically.
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
generated. It
calls saxon with createCommands.xsl to generate the separate batch file
(slides.bat);
calls saxon to generate directoryslide.svg;
starts slides.bat to 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
The earlier createxslbat.xsl version has been discontinued. This XSLT
stylesheet included three functions in one (generation of the command files, the
directoryslide.svg and 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.
03 June, 2001
The makefile mechanism UNIX and cygwin has been added.
07 July, 2001
The re-scaling problem of the included SVG file has been found and settled
The slide background control has been separated from the core.
14 July, 2001
The href attribute is added to TS.
20 August, 2001
Added the span element for TS.
18 September, 2001
The documentation for the schemas have been regenerated, using the latest release of XML
Spy.
03 October, 2001
The compression facility has been added.
15 October, 2001
The compression facility was buggy (the generated links were wrong), needed an overall
rework.
27 October, 2001
The included TS content facility has been added
01 November, 2001
Complete re-write of the documentation
Changed URL into URI for the element names in the TS files.
Beware: older directory description files may have to be adapted.
16 November, 2001
Made some changes in the generated slide (the size are better adapted to the screen
size)
Made the slide more customizable by separating a number of CSS classes into the separate
slide files (see the background CSS file description). If older
slides are reused, the background style file may have to be adapted.
19 November, 2001
Added the facility to turn the logo into an active area.
20 November, 2001
Changed the XML Schema for the directory file to allow the elements within the preamble
part and within the slide element to appear in any order.
Incorporated xalan into the distribution using the system-property function.
The separate note has become superfluous and has been removed.
10 January, 2002
Added the portrait printing facility, and handled a small bug in the
generated makefile with respect to printing.
08 February, 2002
Added the simple image inclusion facility for TS files.
12 February, 2002
Extended the image inclusion facilities to 'left' and 'right'. The documentation has been
restructured, to separate the SDS (new name!) description from the rest.
To be done:
A smoother version of the Windows only (without cygwin)
A macintosh version (?)
A workaround for the DTD problem should be found (why does it create problems with
saxon???)
Right numbers added to printing for US Letter page size
† 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.