There has been several different versions of slidemaker tools floating around W3C, and people used those in function of taste, environment, convenience, etc. This is an attempt to add to the confusion by offering yet another slidemaker tool. However, my concern was to try to reconcile various tastes and demands, so maybe it turns out to be beneficial after all...
The tool I propose is a collection of XSLT stylesheets with four different "entry points" (ie, main, top level templates, all others serving as "utilities" for the run-time). Depending on the entry point, the same source file can be transformed into:
The original source is a simple XHTML file with some restrictions and usage requirements. The restrictions are primarily for alternatives 3 and 4: not all the XHTML elements are converted to SVG. For alternatives 1 and 2 there are no major restrictions. It is important to note the the same source file (commonly known as "all.html") can be used for all four alternatives, ie, the original source can be shared with your colleagues, regardless of what the final format of the generated slides are!
I have made a small writeup on some of the pros and cons of the various versions...
Question of terminology: I refer to an SVG slide for the SVG file generated as an output of the
tool. The content of the slide may be generated from a simple set of XHTML text, from images (png, gif, etc)
enclosed in the XHTML source and from SVG content, ie, SVG an file referred to in the original source
using an <object> statement.
At present, unfortunately, one must use the Saxon XSLT processor. This restriction will become obsolete when XSLT 2.0 processors become more widely available. Saxon is Java based, should run on virtually all environments, and has a precompiled Win32 binary version, called Instant Saxon.
The reason for this restriction is that saxon implements two features of XSLT which is
necessary to run the slidemaker. Both of these features are in anticipation of XSLT 2.0. On the one hand, XSLT
2.0, introduces xhtml as a possible output format; on the other hand, XSLT 2.0 also introduces the notion of a
secondary output tree, controlled by xsl:result-document. Both of these features are implemented
by saxon but, at this moment, in its own namespace.
B.t.w., there is already an alpha release of of Saxon implementing a draft of XSLT 2.0; changing the names of
the functions to the XSLT 2.0 equivalents in the scripts result in a working XSLT 2.0 version of the tools.
(That version has already been tested with this alpha release and the necessary changes in the scripts have
already been added in comments.)
Using Saxon, the command lines for the various alternatives are
saxon -o Overview.html all.html ${TOOL_PATH}/htmlSlides.xslsaxon -o Overview.html all.html ${TOOL_PATH}/htmlSlide.xslsaxon -o Overview.svg all.html ${TOOL_PATH}/svgSlides.xslsaxon -o Overview.svg all.html ${TOOL_PATH}/svgSlide.xslThere is a working example on
Schemas already on the site for an all.html (for those who prefer programming by example...).
This example does not use any SVG content. A more complex example for the results, using also SVG
content, is a presentation on
Semantic Web.
The following rules must be followed in all cases:
<div class="slide"><div class="slide">) must 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 nice 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 elementsobject and img, see
below.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). The
background and border properties for the individual cells are also ignored.
The last restriction is due to the fact that it is very difficult in the current XSLT structure to generate the right background graphics elements. Because SVG 1.2 might give significant additional facilities for texts, I decided not to spend too much time on this now.
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).It is also important to note that the tool does not attempt to calculate the horizontal space a text uses on the SVG slide, hence it does not add any line breaks. The author must add the necessary line breaks (ie, new paragraphs) to cut the lines properly. There are two reasons why this restriction is there at the moment:
The old slidemaker used a separate text file for the inclusion of author, date, logo, etc. This tool does not use a separate file; instead, the original source file should include a series of meta statements to control the output. Also, lot of the customization is in the domain of the included CSS files.
Inclusion of SVG content into the slides raises a number of additional problems. Although these are also managed by the stylesheets, their customization requires additional meta statements. These are described in a separate section. If you do not use embedded SVG, you can safely forget about those.
The generated slide set relies heavily on CSS for styling.
Choosing the CSS files is based on the style file reference in the original source file. For HTML, all
link statements are copied verbatim to the output; for SVG, the corresponding XML processing
instruction is generated using the same basename as in the source but extended with SVG. Ie, if the
all.html refers to a Slides.css file, the corresponding xml statement in the SVG file
will refers to the SlidesSVG.css file.
style statements will be also copied verbatim to the generated HTML and SVG.
The distribution includes a number of CSS file pairs, for HTML and SVG, respectively. The pairs attempt to
produce a somewhat similar outlook to the slides of both formats. A good example is Slides; for
further examples, look at AlternativeStyles subdirectory. Ie, using:
<link href="../xsltSlidemaker/Slides.css" type="text/css"
rel="stylesheet"/>
Will generate proper slides and can be used as an example. It is worth noting that the CSS settings in this file are such that even the original file can be used in projection mode, albeit no signature, slide number, etc, will be present and the outlook has not been optimized (yet).
meta statements (with examples and possible
default values)Note that the default values can be changed at installation, by modifying their values in
common.xsl.
<meta name="Author" content="Ivan Herman"/>Several authors may be listed each separated by commas, with corresponding URL-s in the
AuthorURL statement below, again separated by commas. The tool creates active links with
the corresponding pairs. If the Author statement includes more strings in the comma
separated list than corresponding URL-s, the remaining part will be copied verbatim without any
link.
<meta name="AuthorURL" content="mailto:ivan@w3.org"/><meta name="Copyright" content="©...."/>Default value:© 1994-2004, W3C (MIT,ERCIM,Keio)
<meta name="CopyrightLink" content="http://...."Default value: http://www.w3.org/Consortium/Legal/copyright-documents
<meta name="Organization" content="W3C - ..."Default value:W3C - World Wide Web Consortium
<meta name="Date" content="16 July, 2002"/><meta name="Logo" content="../icons/w3chome.png"/>Default value: none
<meta name="LeftArrow" content="../icons/left.png"/>Default value: ../icons/left.png
<meta name="RightArrow" content="../icons/right.png"/>Default value: ../icons/right.png
<meta name="UpArrow" content="../icons/up.png"/>Default value: ../icons/up.png
<meta name="indexPage" content="Overview"/>.html and
.svg suffixes, is referenced by the "up arrow" of the navigation bar in the HTML and SVG
slides, respectively. It is a good idea to choose a name corresponding to the default index name used
by the server where the slides will be stored (if made available on-line). This allows using URL-s of
the form http://a.b.c/, for example.
Default value: Overview
<meta name="Event" content="The Fantastic XML Workshop"/><meta name="SlidesURL" content="http://www.w3.org/2002/Talks/MyTalk/"/>Obviously, the left, right and up arrows will be ignored if a single file is generated with
htmlSlide.xsl. These statements are also ignored by the SVG output (which uses its own arrow
figure).
The following statements are used by the SVG output only:
<meta name="Logo_W" content="72"/><meta name="Logo_H" content="48"/>Default values: 72 and 48, respectively.
If the default (W3C) is used, these statements are not necessary; actually, the generated SVG slides contain the SVG logo in SVG and not as an image.
A number of variables, governing the slide generation (default values for the meta statements, SVG slide dimensions, etc) can be customized by changing variables in the XSLT files. The two files which are of interest in this respect are:
common.xslsvgCommon.xslInclusion of SVG into an XHTML presentation slides is the source of some further headaches:
This means, in other words, that even if one works with a "pool" of SVG files that are reused all the time, those files should be copied to a separate place before publishing (ie, freezing) the content. The slidemaker tool provides automatic means to do that.
object), and if all files are on a remote site and
if the SVG file uses a relative URL to another object (CSS file, images, etc), then the
presentation freezes. In other words, all the URI-s in the SVG files must be absolute. On the
other hand, if you do not want to be dependent on the Internet for the presentation, the files should
use relative URL-s on your local disc...
The solution is that all URL-s should be turned absolute before publishing them. This is a royal pain, but the slidemaker tries to give some help, too.
What the tool does is:
object statements are simply copied to the output without change.SVGMove=true argument (ie, setting a parameter in the
stylesheet), each SVG file (whose reference is retrieved from the object elements) is
copied to another directory, and the object elements are updated when copied to the
output.
While copying the SVG file, all URL-s in the file are changed on the fly, following a pair
of "from" and "to" patterns. The "to" pattern may refer to an absolute URL, which is used by default,
or a relative URL, which is used if saxon is invoked with a further SVGURLs=relative
argument.
Similarly to the URL patterns in the SVG file, an absolute or a relative URL can be given referring
to an external stylesheet. The xml-stylesheet processing instruction will be added to the
SVG file being copied.
The patterns and the CSS URL-s can be controlled by a series of meta statements in the source
file.
The meta statements are as follows:
<meta name="svgs" content="svgs/"/>Default value: svgs/
<meta name="cssURLRel" content="../../svgs/slide.css"/><meta name="cssURLAbs"
content="http://www.w3.org/Consortium/Offices/Presentations/svgs/slide.css"/><meta name="fromPattern" content="../"/><meta name="HTMLToPatternRel" content="../../"/><meta name="toPatternAbs"
content="http://www.w3.org/Consortium/Offices/Presentations/"/>To offer a finer control, these global statements can be overridden on each object. It may
indeed necessary to have a different "to" of "from" pattern for a particular SVG content file. This can be done
by using special attributes on the <object> element, which are in a separate namespace. The
attributes' local name are identical to the meta statement's name and the value is identical to the possible
meta content. The separate namespace is set to:
http://www.w3.org/Consortium/Offices/Presentations/xsltSlidemaker/. As an example:
<html xmlns:slide="http://www.w3.org/Consortium/Offices/Presentations/xsltSlidemaker/" ...>
<head>.....<head>
<body>
<div class="slide">
....
<object slide:fromPattern="../" ....>
....
</object>
</div>
</body>
</html>
All this is, admittedly, messy. Some of this might disappear in future, when the relative vs. absolute bug will be handled, but some won't.
Even with all the precautions described in the previous section the author might want to publish an HTML version of the slides without SVG content at all (possibly publishing pure SVG slides as an alternative). What this means is:
img element as a child of object, orobject element to a img element altogether.If the htmlSlide.xsl or htmlSlides.xsl entry points are used, one can use the
SVGtoImage parameter. By default, the parameter has no effect. However, if the value is set to
extend (resp. replace), however, the two actions described above are performed,
respectively.
The generated img element uses the $svgs/{basename}.png pattern to generate the
right file name. Ie, the images should be in PNG format, stored in the same directory as the copy of the SVG
files (as described in the previous section).
The generated img element does not have any dimensions; in other words, the image has to be of
the right size. There is an extra tool to achieve this: the imgCommands.xsl file can generate a
set of commands with the right width and height values for each SVG file (in case a tool is used to convert SVG
into PNG).
In the case of SVG slides, the content of the original SVG files (ie, referred to by a object
element) is copied onto the slide. This means that most of the complications, described above, do not apply for
this case, except for the on-the-fly change of the URL-s in the file. Even in that case, only the relative
pattern is relevant.
To control the external CSS style sheet, a separate meta statement can be used:
<meta name="cssSVGSlideIncl" content="../svgs/slide.css"/><meta name="SVGToPatternRel" content="../svgs"/>There are some restrictions and positioning possibilities when images or svg objects are used in the original source file. These are:
img or object can appear on the slide, and this must be either the
first or the last element on the slidediv
class="center".XHTML does not require the width and height attributes for images or objects; but
these attributes may be given either as explicit attributes or part of a style element (actually, in XHTML
strict only the latter is allowed). If these attributes are specified, the tool uses them to set the
right size, otherwise 100% is used for both. If the image is enclosed in a div class="center", the
image will be positioned in the middle.
Be default the image/object is followed or preceded by the text, depending on the position of the image
element within the slide. However, the float:right or float:left style attributes are
also understood and the placement of the text will mimic the behavior.
Note that IE6 does not implement the float:right and float:left
attributes properly for objects (it does for images). That means that slides prepared for both outputs will
look different ;-(
In general, users can adapt the outlook of their slides by playing with the CSS files, but that is not always possible. An additional possibility is to force the tool to include an svg pattern, that is included on each slide and is used by the background of the full slide (using the SVG's pattern filling feature. An example for such a pattern is, for example:
<pattern xmlns="http://www.w3.org/2000/svg" id="_Background"
patternUnits="userSpaceOnUse" x="0" y="0" width="1220" height="8">
<path d="M0 0 h1220 v3 h-1220 z" class="AquaLine"/>
</pattern>
(Note the id attribute that must be present; the namespace declaration is also necessary to run
this code through the XSLT processor).
By using the meta statement of the form:
<meta content="AlternativeStyles/W3C.xml" name="SVGBackgroundXML"/>
one can force the tool to include the SVG pattern into the final code and the background will make use of that pattern instead of a solid colour.
If you know SVG you might realize that, strictly speaking, this statement should not be necessary. According to the specification of SVG one could store such a pattern in a separate SVG file, and use CSS to associate a class with a pattern. Alas! This does not work in the current version of the SVG plugins, hence this meta statement. If future versions of the plugins implement this feature, this meta statement will become obsolete.
By using a pattern one may also want to control the size of the display area (the slide content). By default, this area maximizes the available real estate. However, the user may use some further meta statements to control those:
<meta name="W" content="1220"/>Default value: 1220
<meta name="H" content="9150"/>Default value: 915
<meta name="sW" content="14"/>Default value: 1170
<meta name="sH" content="900"/>Default value: 795
<meta name="sX" content="14"/>Default value: 25
<meta name="sY" content="14"/>Default value: 80
By default, the tool also generates a separate title page (0.html and 0.svg for
the HTML and the SVG slides, respectively). This page shows the author, the date of the presentation, and the
overall title, as retrieved from the meta elements. The values for the meta elements Event and
SlidesURL are also used (see the list of available meta elements).
This feature can be switched off by starting up the XSL tools with the TitlePage=false
parameter.
htmlOnly and svgOnly classes setting the display to
none for their respective version. Ie, one can adapt, say, a bulleted list if an overflow
cannot be avoided in SVG, but still let the HTML do its job in wrapping the content automatically. As an
extra convenience (in case only one CSS file is used, for example), a div with the class set
to htmlOnly will be silently ignored from the generated SVG slides.div class="prologue"; this will be copied verbatim to
the HTML overview file, right before the table of content (authors can use this to add some additional
information on the presentations, for example).Unfortunately, these scripts are not 100% kosher. The problem is that SVG1.0 does
not define keypress events, although both the Adobe and the Batik browsers implement it. In
other words, this script will work with those browsers only and other browsers might complain. To
switch this facility off, the xslt script must be started with the KeyPress=false
parameter.
Navigation=false parameter, these arrows are not generated.
This feature seems unnecessary. However, if the slides are used by another tool to navigate automatically (eg, by using a suitable SMIL file), it better to switch navigation off to avoid interference.
slide:fold="true" on a li element, which itself includes a
ul list, the sub-list will not be displayed by default and can be interactively
unfolded/folded by clicking on the bullet character. This works much like a usual file-listing treeview.
This works only in the SVG slides, though (and is implemented through a small piece of ecmascript).http://www.w3.org/Consortium/Offices/Presentation/xsltSlidemaker#slideContent.
This means that
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. Indeed, most servers are set up to serve XHTML files as iso-8859-1. If your slides do not contain any "non-ASCII" characters, you do not really care. Otherwise, there are two ways to handle that.
.htaccess files
should then contain:
<Files ~ "*\.html">
ForceType 'text/html; charset=utf-8'
</Files>
htmlSlides.xsl and htmlSlide.xsl. (The reason this is not more flexible is
because, in XSLT, the xsl:output element, which also includes encoding information, cannot be
parametrized...)If you want a relatively stable version, you can download a compressed tar file. This includes all the files and, to simplify installation, also includes instant saxon for Windows machines. The links below point at the files which are on our server; although every effort is made to store only bug-less versions on the server, problems may occur.
The following xsl files must be downloaded:
common.xsl |
Common routines used by all |
htmlCommon.xsl |
Routines used for the XHTML generation |
htmlSlide.xsl |
Entry point for the projector mode generation |
htmlSlides.xsl |
Entry point for the generation of XHTML slide files and an overview file |
svgCommon.xsl |
Routines used for the SVG generation |
svgSlide.xsl |
Entry point for the generation of one single SVG file |
svgSlides.xsl |
Entry point for the generation of a series of SVG slides |
imgCommands.xsl |
An extra tool to generate the right commands for SVG to PNG conversion. A variable at the start of the file contains the command name that is generated. |
The following CSS file can be used as example:
Slides.css and SlidesSVG.css |
General pair of CSS statements used by the original source and the generated files in all viewing conditions. |
Some other Style files have also been added to the subdirectory AlternativeStyles, just for the
sake of trying...
The slide file on Schemas and the slide file on Semantic Web can also be used as examples for a source files. The former relies on all the defaults and does not content any SVG element.
This is just a reminder of the various commands and their parameters. For the explanation see the text itself.
Using Saxon, the possible command lines for the various tools may be (using Overview as an
index page basename):
saxon -o Overview.html all.html ${TOOL_PATH}/htmlSlides.xslsaxon -o Overview.html all.html ${TOOL_PATH}/htmlSlide.xslsaxon -o Overview.svg all.html ${TOOL_PATH}/svgSlides.xslsaxon -o Overview.svg all.html ${TOOL_PATH}/svgSlide.xslsaxon -o CommandFile all.html ${TOOL_PATH}/imgCommands.xslThe possible parameters (using the saxon syntax and to be added to the end of the command line) are:
htmlSlides and htmlSlide):SVGMove={true|false} (default: false)true, the object references are changed to refer to svgs/FILEbasename,
and a copy of the SVG files are made in the svgs subdirectory. (The exact location of
the result can be controlled through a meta element).SVGURLs={relative|absolute} (default: absolute)SVGtoImage={extend|replace|none} (default: none)img elements should extend or replace the object
elements referring to an SVG contentTitlePage={true|false} (default: true)See the separate section handling XHTML+SVG for details
svgSlides and svgSlide):SVGURLs={relative|absolute} (default: relative)TitlePage={true|false} (default: true)KeyPress={true|false} (default: true)svgSlide, only for svgSlides.Navigation={true|false} (default: true)svgSlide, only for svgSlides.ZippedReferences={true|false} (default: false)See the separate section for details
Note that most of these parameters are relevant when using SVG for the image content. If no SVG is used, they can be safely forgotten...
These are only subjective notes on using the various alternatives. The truth is: all four possible slide formats have pros and cons!
This output can also be used for printing; the CSS files have some additional, media specific statements for this. Problem may occur with included SVG images, though, you may have to adjust the vertical size for printout.
Personally, what I tend to do these days is:
The reason why I use image references only with HTML is because too many browsers, alas!, still break on the
object statement with SVG (eg, Mozilla...). Ie, if I use SVG content (personally, I almost always
do) in the original slide, I convert the SVG content into images. This can be done in two steps:
imgCommands.xsl script to generate a command line
sequence for batik; this will define the image sizes;Of course, the first step can be omitted, but you will have to play to resize the images manually.
I publish the SVG slides, the HTML slides and, possibly, the PDF file. I also add a prologue to the source file linking to the SVG slides as well as to the HTML file and, if applicable, to the printable file. By doing this, the casual user, without an SVG enabled browser, can also look at the content, possibly print them, while SVG users can enjoy the SVG slides. One day, when SVG will be everywhere (...) all this might become superfluous...
For the usage of a W3C SVG "style" close to the W3C version of JackSVG's output (though not identical), you can set the following link/meta statement in your source:
<link href="xsltSlidemaker/AlternativeStyles/W3C.css" type="text/css" rel="stylesheet" /> <meta content="AlternativeStyles/W3C.xml" name="SVGBackgroundXML" /> <meta content="160" name="sX"/> <meta content="1035" name="sW"/>
and no logo should be set (it is part of the images loaded into the background). The slide sheets for HTML are prepared for a 1024x768 screen size (all projectors work with these resolutions only these days) which affects the positioning of the logo on the lower left hand corner of the screen. Of course, the SVG slides are agnostic to screen size, they re-scale anyway...
If you also provide a PDF version for printing, beware that browsers do not print optimally (yet). Some of the background images might be missing, for example (in any case, you should set the browser preferences to print background colours and images). My best experience so far is to print with IE, although that is far from being perfect either.
Some of the presentations are so graphic oriented that it makes it a bit unnecessary to create HTML versions, SVG should suffice. This, however, may lead to problems if the conference organizers want a printout, for example. On the other hand, printing SVG is still somewhat of a problem. This is what I do:
Files -> Automation Tools
-> PDF Slideshow...). This can be used to create a PDF file using the images.The result is a PDF file that can be printed (use landscape mode when printing!). Ie, the PDF file can be sent to organizers, if this is what the organizers want...
Note: changes have been properly logged starting January 2003 only; this is when I had the first outside user of the package (that I know of)...
Navigation parameter.indexPage meta statement. In
previous version, the basename Overview was hardwired in the code.SeparateCSS meta statement and made the default
value true in the code. In previous versions, the default was to use the same CSS file for
HTML and SVG. Although this is, theoretically, correct, mixing SVG and HTML CSS statements was not accepted
by, eg, batik, and the Adobe plugin for SVG complained, too. I therefore introduced the
SeparateCSS meta statement, albeit with a default value false, which
implemented the CSS policy described now in this document. Because this is the only
really sensible value these days, the default value is now true and the meta
statement is not really necessary, hence not documented any more. If you have problems with older slides,
using this meta statement with a value of false will implement the deprecated
behavior.metadata and
foreignElement content is copied blindly, all others are copied with the possible on-the-fly
modification of their xlink:href attributes.Copyright © 1994-2003 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.