$Date: 2002/02/20 13:50:14 $
Docs
directory.
Copyright © 1999-2001 W3C® (MIT, INRIA, Keio), All Rights
Reserved. W3C liability, trademark, document use and
software
licensing rules apply.
svgSlidemaker
directory.xml
slides
author
elementURL
elementtitle
elementdate
elementorigin
elementtextOrigin
elementcss
elementbackgroundCss
elementbackgroundPattern
elementURIReplacement
elementlogo
elementrasterizer
elementpage
elementslide
elementdirectory.xml
filesvgSlidemaker
on Windows without
cygwinThe 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:
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 ofxalan
does not include the necessaryRedirect
extension, in spite of its on-line documentation. Users have to installxalan
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.
svgSlidemaker
Generating a slide set with svgSlidemaker
is done through the following
steps:
directory.xml
filemake
to generate the complete slide setIt should be emphasized that this tool does not help in the second step!
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:
directory.xml
file changes,
all slides will be regenerated. This is the default target.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.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.
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.
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.
viewBox
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
.
directory.xml
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 ).
slides
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.)
Attribute:
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
author
element<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.
URI
element<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.
title
element<xsd:element name="title" type="xsd:string"/>
The title of the full presentation.
date
element<xsd:element name="date" type="xsd:string"/>
The date of the presentation. Will appear on the lower right hand corner of every slide.
origin
element<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.
textOrigin
element<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.
css
element<xsd:element name="css" type="xsd:string"/>
Name of the CSS file used for the content of the slide.
backgroundCss
element<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
example.
backgroundPattern
element<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>
Attributes:
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.
URIReplacement
element<xsd:element name="URIReplacement"> <xsd:attribute name="from" type="xsd:string" use="required"/> <xsd:attribute name="to" type="xsd:string" use="required"/> </xsd:element>
Attributes:
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.
logo
element<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>
Attributes:
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.
rasterizer
element<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>
Attributes:
This attribute controls the printing/HTML generation facility, described separately below.
page
element<xsd:element name="page" type="xsd:string"> <xsd:attribute name="orientation" type="xsd:string" use="required" default="landscape"/> </xsd:element>
Attributes:
This attribute controls the printing/HTML generation facility, described separately below.
slide
element<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.)
Attribute:
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.
title
element<xsd:element name="title" type="xsd:string"/>
The title appears on the top part of the slide.
tooltip
element<xsd:element name="tooltip" type="xsd:string"/>
The tooltip is used when the mouse rolls over the arrows linking the slides.
file
element<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
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.
Attribute:
<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
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:
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;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 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.
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.
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).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:
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).metadata
section exists in the enclosed SVG file, this is "moved" to
the top level.directory.xml
file<slides compress="true"> <author>Ivan Herman (ivan@w3.org), Head of Offices</author> <URI>mailto:ivan@w3.org</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>
svgSlidemaker
on
Windows without cygwinYet 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
createCommands.xsl
to generate the separate batch file
(slides.bat
);directoryslide.svg
;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
directory.xml
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.href
attribute is added to TS.span
element for TS.URL
into URI
for the element names in the TS files.
Beware: older directory description files may have to be adapted.slide
element to appear in any order.a
element to TS.xalan
instead of
saxon
.system-property
function.
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.