Everything is an beta version, including the documentation!

A Combined Slidemaker
(or: "How to make everybody happy"?)

Table of Contents

  1. Introduction
  2. Constraints on the source XHTML file
  3. Customization of the output
    1. CSS File
    2. Available meta statements
    3. Customization on XSLT level
  4. Management of SVG content
    1. XHTML Slides
    2. Conversion to images
  5. SVG SLides
  6. Generation of a Title Page
  7. Miscellaneous
  8. Language Setting and Character Encoding
  9. What to download
  10. Overview of commands and parameters
  11. For W3C Team and Office staff
  12. Printing from SVG slides only
  13. Changes

Introduction

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:

  1. A series of XHTML (note the 'X'!) slides, linked into a sequence. This is a more "modern" version of the old slidemaker, but using XSLT instead of a perl hack.
  2. One single XHTML file, including all the slides, and prepared for the CSS2 "projection" mode usage. The output of each slide is essentially identical to the individual slides of the previous alternative, but everything is bound to one file.
  3. A series of SVG slides, linked into a sequence.
  4. One single SVG file, using an SVG animation tricks to step through the individual slides.

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.

Invoking the slidemaker

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

  1. saxon -o Overview.html all.html ${TOOL_PATH}/htmlSlides.xsl
  2. saxon -o Overview.html all.html ${TOOL_PATH}/htmlSlide.xsl
  3. saxon -o Overview.svg all.html ${TOOL_PATH}/svgSlides.xsl
  4. saxon -o Overview.svg all.html ${TOOL_PATH}/svgSlide.xsl

Constraints on the source XHTML file

There 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:

The file must be XHTML
Obviously, this is necessary for XSLT...
The file must have a title in the header
This is a good practice anyway... but this will be used to set the title of the full presentation!
Each slide must be enclosed by a <div class="slide">
This element is the "trigger" to separate the slides. At present, any element "outside" these div-s are simply ignored. This might be a bit of a pain at first, but it does help in properly organize the source file!
Each slide (ie, each <div class="slide">) must begin by a h1 and this must be the only usage of h1-s
These elements are used to set the title for each individual slide
SVG content must use the object statement
Ie, embed is not recognized (yet?). The dimensions of the object can be given either in percentages or in fixed values, both as attributes or as style attributes.

The 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:

The following modules/elements are not managed (yet?):
base and form modules
br, address elements
there are restriction on the usage of the object and img, see below.
Limited handling of tables
none of the "fancy" things (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.

List numbering
The 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 types
The 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!).
(In contrast to XHTML Basic) the style element is also understood
the content is usually copied verbatim to the SVG output as a style 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:

  1. Doing this in pure XSLT is not feasible: not only it involves lots of calculations, but it should also rely on the font descriptions. I was too lazy to do something like that.
  2. SVG 1.2, which might have its first implementations around in 2003, will include a flow text control doing exactly what we need. I decided to let the SVG 1.2 implementors sweat on this issue and use their output! In the meantime, one has to be a bit more careful with the input text.

Customization of the output without SVG content

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.

CSS usage

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).

Available 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"/>
This will be used as part of the signature of each slide as well as on the title page.

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"/>
If this statement exists, the authors' name on each slide is turned into a link to this URL.
<meta name="Copyright" content="...."/>
The content of this statement will be added to the signature of the generated HTML slides. This value will be used in the rdf metadata generated into SVG slides. Otherwise, the SVG slides do not use this statement; use the styling and pattern possibilities instead to place the copyright statement.

Default value: 1994-2004, W3C (MIT,ERCIM,Keio)

<meta name="CopyrightLink" content="http://...."
The copyright note, if exists, will be turned into an active link with this URL for generated HTML slides. This value will be used in the rdf metadata generated into SVG slides.

Default value: http://www.w3.org/Consortium/Legal/copyright-documents

<meta name="Organization" content="W3C - ..."
This meta will be used in the rdf metadata generated into SVG slides.

Default value:W3C - World Wide Web Consortium

<meta name="Date" content="16 July, 2002"/>
This will be used as part of the signature of each slide.
<meta name="Logo" content="../icons/w3chome.png"/>
Image used as a logo on each slide

Default value: none

<meta name="LeftArrow" content="../icons/left.png"/>
Image used for the link to the preceding slide

Default value: ../icons/left.png

<meta name="RightArrow" content="../icons/right.png"/>
Image used for the link to the next slide

Default value: ../icons/right.png

<meta name="UpArrow" content="../icons/up.png"/>
Image used for the link to the index (a.k.a. overview) page

Default value: ../icons/up.png

<meta name="indexPage" content="Overview"/>
Base name of the index page. This name, extended with the .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"/>
This value is used for the separate title page; if set, the content will appear on the title page. It is typically used to denote the event (conference, workshop, etc) where the presentation is made. There is no default value.
<meta name="SlidesURL" content="http://www.w3.org/2002/Talks/MyTalk/"/>
This value is used for the separate title page; if set, the content will appear on the title page. It is typically used to denote the URL where the slides are stored. There is no default value.

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"/>
The height and the width of the logo, respectively. SVG requires those attributes, whereas XHTML does not...

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.

Customization on the XSLT level

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.xsl
is the file used by all other XSLT files. Most of the general meta default values can be customized by changing the variables at the top of the files
svgCommon.xsl
is the file used for the SVG Slide generation. Some of the variables, governing the output, can be changed at the top of the files. For the connoisseurs of SVG, the arrows, the frame around the content, or the default W3C logo can also be adapted.

Management of SVG Content

XHTML Slides

Inclusion of SVG into an XHTML presentation slides is the source of some further headaches:

What the tool does is:

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/"/>
Relative URL to use for storing the copied SVG file. The basename of the original will be appended to this string to produce the right file name.

Default value: svgs/

<meta name="cssURLRel" content="../../svgs/slide.css"/>
Relative URL for an included CSS file when SVG files are copied. If the content is empty (or the meta statement is missing) no stylesheet reference is generated.
<meta name="cssURLAbs" content="http://www.w3.org/Consortium/Offices/Presentations/svgs/slide.css"/>
Absolute URL for an included CSS file when SVG files are copied. If the content is empty (or the meta statement is missing) no stylesheet reference is generated.
<meta name="fromPattern" content="../"/>
Initial pattern of URL-s which have to be changed while copying an SVG file
<meta name="HTMLToPatternRel" content="../../"/>
Pattern to be used to replace the "from" pattern when relative URL-s are generated
<meta name="toPatternAbs" content="http://www.w3.org/Consortium/Offices/Presentations/"/>
Pattern to be used to replace the "from" pattern when absolute URL-s are generated

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.

Conversion to Images

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:

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).

SVG Slides

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"/>
(Relative) URL for the additional CSS file for SVG slides. This is used to control the appearance of the incorporated SVG file.
<meta name="SVGToPatternRel" content="../svgs"/>
(Relative) URL for the included SVG content

Images and objects

There are some restrictions and positioning possibilities when images or svg objects are used in the original source file. These are:

  1. Only one img or object can appear on the slide, and this must be either the first or the last element on the slide
  2. Inline images (ie, within a paragraph) are not understood
  3. These elements must be either top-level within the slide, or be enclosed in a div 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 ;-(

Finer customization of SVG slides (only for connoisseurs!)

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"/>
Width of the slide

Default value: 1220

<meta name="H" content="9150"/>
Height of the slide

Default value: 915

<meta name="sW" content="14"/>
Width of the slide content rectangle.

Default value: 1170

<meta name="sH" content="900"/>
Width of the slide content rectangle.

Default value: 795

<meta name="sX" content="14"/>
X coordinate of the slide content's top left corner.

Default value: 25

<meta name="sY" content="14"/>
Y coordinate of the slide content's top left corner.

Default value: 80

Generation of a Title Page

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.

Miscellaneous

Language Setting and Character Encoding

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.

  1. Set up the server appropriately. For example, on an Apache server, the .htaccess files should then contain:
    <Files ~ "*\.html">
    
        ForceType 'text/html; charset=utf-8'
    
    </Files>
    
  2. You can insist on using another encoding, but you have to change the encoding on the top of the 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...)

What to download

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.

Overview of the commands and the possible parameters

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.xsl
Produces a presentation consisting of a series of HTML files
saxon -o Overview.html all.html ${TOOL_PATH}/htmlSlide.xsl
Produces a presentation consisting of a single HTML file, prepared for the CSS projection mode
saxon -o Overview.svg all.html ${TOOL_PATH}/svgSlides.xsl
Produces a presentation consisting of a series of SVG files
saxon -o Overview.svg all.html ${TOOL_PATH}/svgSlide.xsl
Produces a presentation consisting of a single SVG file
saxon -o CommandFile all.html ${TOOL_PATH}/imgCommands.xsl
Generation of a command file (usable, for example, with a UNIX shell) to generate images from SVG files (using, eg, Batik) with the right image sizes. These images can then be used in the HTML version of the slides.

The possible parameters (using the saxon syntax and to be added to the end of the command line) are:

For HTML files (htmlSlides and htmlSlide):
SVGMove={true|false} (default: false)
By default, SVG contents are not treated differently. If the parameter is set to 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)
If SVG-s are manipulated, the relative URL-s in the files have to be changed on the fly. The meta elements control what the manipulation should be for absolute and relative.
SVGtoImage={extend|replace|none} (default: none)
Whether HTML img elements should extend or replace the object elements referring to an SVG content
TitlePage={true|false} (default: true)
Whether a separate title page should be generated or not.

See the separate section handling XHTML+SVG for details

For SVG files (svgSlides and svgSlide):
SVGURLs={relative|absolute} (default: relative)
If SVG-s files are included in the final slide, the relative URL-s in the files have to be changed on the fly. The meta elements control what the manipulation should be for absolute and relative.
TitlePage={true|false} (default: true)
Whether a separate title page should be generated or not.
KeyPress={true|false} (default: true)
Whether a keypress navigation should be generated or not. This parameter is not valid for svgSlide, only for svgSlides.
Navigation={true|false} (default: true)
Whether a navigation arrows are generated or not. This parameter is not valid for svgSlide, only for svgSlides.
ZippedReferences={true|false} (default: false)
Whether the references to other SVG slides should refer to an '.svg' or an '.svgz' suffix. Note that the user is responsible to zip the generated SVG files.

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...

When to use what?

These are only subjective notes on using the various alternatives. The truth is: all four possible slide formats have pros and cons!

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:

  1. Use the separate imgCommands.xsl script to generate a command line sequence for batik; this will define the image sizes;
  2. Convert the SVG files into PNG using batik.

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 W3C Team and Office staff

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.

Printing from SVG slides only

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:

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...

Recent Changes

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)...


Ivan Herman, Head of Offices (ivan@w3.org)
Last revised: $Date: 2004/02/13 08:05:31 $