LWN.net Weekly Edition for September 16, 2004

The Grumpy Editor's guide to presentation programs

This article is part of the LWN Grumpy Editor series.

A sad, but common experience in the 1990's was to see presentations at Linux conferences which were clearly done with PowerPoint. When Linux advocates need to use a 100% proprietary system to communicate with their audience, something is clearly wrong. Fortunately, those days are behind us, and PowerPoint only makes appearances in irrelevant corners at Linux events - LinuxWorld keynotes, for example.

Your editor has given a fair number of talks this year in a number of exotic locales, and that trend looks set to continue. So presentation software is an area of interest; it is time to look at the current state of the art. Your editor has found that, while the situation is better than it has ever been, there is still room for improvement.

For what it is worth, here are some of the criteria which are to be used when evaluating free presentation systems:

• The visual quality of the output. One assumes that the audience will actually look at the slides when not heckling the speaker over IRC, so the appearance of the slides will affect the overall impression left by the talk. So things like clean transitions and antialiased fonts are important.

• Responsiveness. If the speaker has to wait for the next slide to appear on the screen, something is wrong.

• Random access. Questions from the audience can require moving around quickly in the talk; the presentation program should provide random access to any slide without a lot of trouble.

• Easy creation of slides. It is bad enough to be finishing a talk, with a hangover, an hour before it is supposed to be presented. If the presentation system makes slide creation slow or laborious, such a situation can become intolerable. It should be possible to bash out slides - especially simple slides, with a minimum of effort.

• Control. It should be possible to get rid of all those bullets, achieve decent inter-line spacing, set code in a monospace font, etc. without great effort.

• HTML output. People like it when the slides from a talk are posted to the web; this should be a straightforward operation.

One thing which is not on your editor's list is nine-step special-effects dominated slide transitions, trapeze-act bullet points, bouncing penguins, etc. In your editor's grumpy opinion, such effects can only serve to distract attention from the actual substance of the talk. Good presentations can only be harmed by turning the slides into a cartoon show, and bad presentations cannot be saved that way.

There are two fundamental approaches to presentation programs: graphical editors and markup languages. Your editor found two active projects of each type; we'll start with the graphical entries.

KPresenter

KPresenter is the KDE project's presentation package. It has come a long way in recent years, becoming a powerful, fully-featured system with something for just about everybody. Basic text is easy to enter, with nice fonts and full control over presentation. Spell checking is built into the application. There is a simple drawing capability which includes the ability to make connections between objects - a crucial feature when presenting this week's new organization chart. Objects can be rotated and have drop shadows added on to them.

KPresenter can import images in numerous formats - including PostScript and SVG. Tables and charts can be generated with a simple, spreadsheet-like data editor. It is also possible to import various KOffice objects directly. If you present a lot of pie charts, this package is for you. If you want animations and singing, dancing transitions, KPresenter will provide them for you as well.

There is a basic set of templates which can be used to control the overall formatting of presentations. The first time you use KPresenter, it can be a little hard to figure out how to quickly make it add a new slide with the same template - but it is possible. A "preview" window on the left side can be used to navigate through the slides while editing them.

KPresenter works as one would expect when presenting; the output quality is good, and the program is responsive. A quick right-click brings up a list of slides for random movement. KPresenter also offers a "drawing mode," which lets the presenter scribble on the slides with a mouse. As a nice touch, KPresenter makes the pointer disappear while presenting. It's surprising how few presenters think to move the pointer to a corner, and give their entire talk with an unrelated arrow in the middle of their text; with KPresenter, they need not worry about that little detail.

Generation of HTML with KPresenter is a matter of stepping through a set of dialogs allowing customization of the output. HTML configurations can be saved, making things easier the second time. The quality of the output is good.

Your editor, working with the Fedora Rawhide packaging of KPresenter 1.3.2, encountered a few occasional bugs. Try to create a presentation with the wrong template, and the whole thing just silently quits. There are minor annoyances: when editing presentations, it is nice if the tab key increases the bullet level, but KPresenter does not work that way. The online documentation is spotty, with detailed tutorials on some relatively simple operations, but no help for more obscure topics, such us using the "autoform" feature.

Those issues are all minor, however. KPresenter is clearly a mature and capable package for the creation of presentations. If it were the only option available for free systems, we would be in good shape.

OpenOffice.org

One of the many features built into OpenOffice.org is a presentation package. Like KPresenter, OOo is a fully graphical editor, and it, too, is packed with features.

If you want to make fancy drawings, OOo is even more feature-rich than KPresenter. It has various types of curve drawing operations, and a set of three-dimensional objects as well. If you are giving a talk which relies heavily on 3D, ray-traced cones and toruses, OOo is the package for you. It can do connections between objects. The graph editor also looks very similar; type your data into the spreadsheet window (or import an OpenOffice spreadsheet) and any sort of 3D plot is available to you. There is a brutally long list of available slide transitions.

OpenOffice offers a number of ways of viewing and navigating through a presentation while working on it. A small set of tabs on the bottom of the window is one such view; to make the tabs useful, however, the user must explicitly set the title which appears on each one. There is an "outline view" which lists the bullet points as text, a "slide view" for seeing the presentation in thumbnail format, and a "notes view" which presents additional speaker notes.

The presentation mode works mostly as expected. It is possible to pull up the navigator and move to an arbitrary slide, but you must know that F5 is the magic key to hit. Some of the slide transitions and bullet effects, if, for some reason, you choose to use them, can take a long time and do not appear to be interruptible. There is a rehearsal mode which puts a stopwatch on the screen so you can see how long each slide takes - but it does not seem to time the entire presentation. There is no on-screen drawing mode.

OpenOffice has a dialog-driven HTML export mechanism which allows customization of almost every aspect of the output and works reasonably well. The program can also export to PDF, but it seems to get confused by animated text effects - yet another good reason to avoid them. The PDF output also seems to lack many of the graphical objects in the slides; instead, it contains only the text.

OpenOffice.org differs from KPresenter in one key aspect: how templates are handled. KPresenter generates each page from the template at insertion time; thereafter, the page is disconnected from the template. OpenOffice, instead, derives pages from a "master" page, and keeps that connection. As a result, changes affecting the layout of the entire presentation can by made by editing the master pages. With KPresenter, instead, it is necessary to change each page individually.

Anybody who has worked with OpenOffice.org knows that it is a large, unwieldy program. Once it gets going, it responds reasonably well, however. Once again, the online documentation is not all that one might hope for. If you want text with drop shadows, OpenOffice will disappoint you. If you want a capable, graphical presentation package, however, OpenOffice can certainly fill the bill.

MagicPoint

MagicPoint takes a very different approach to the problem of editing presentations. This tool (along with Pointless, which we will get to shortly) is based on plain text files and a custom markup language. Editing of slides is done with an ordinary text editor; the resulting file must be fed to the utility to see the final result.

To many, this approach will seem like something straight out of the 1970's. There are advantages to doing things this way, however: the creation of simple, textual presentations can be done very quickly, and the plain text input file can provide extensive control over how the presentation works. Purists will tell you that the markup approach helps to focus the mind on the structure of the presentation rather than its appearance. That may be true, but presentations are also very much about appearance, so users of markup-based presentation programs usually end up checking the formatting of their slides frequently as they write them.

MagicPoint's markup language takes a bit of getting used to. There is a simple template for each page which describes how each line should be formatted. In a typical MagicPoint presentation, the first line of a slide is blank, the second holds the title, the third is blank, and the slide text starts on the fourth line. Bullet levels are determined by the number of tabs at the beginning of the line. The result is that a MagicPoint input file tends to look like an outline of the talk with a bit of markup language thrown in.

The markup language is fairly straightforward: %page to start a page, %font to change fonts, etc. MagicPoint can use TrueType fonts for high-quality output. If you change fonts frequently (using monospace fonts for code fragments, for example), MagicPoint's markup can get verbose and cumbersome; otherwise it is pretty unobtrusive. There is simple support for background images or gradients. There are no operations for creating graphics in slides beyond drawing solid rectangles, but MagicPoint can easily display images stored in external files. So, to create a slide with graphics, one need only fire up one's favorite editing tool and export the result as a PNG file.

In presentation mode, MagicPoint behaves much like the others. It has an on-screen drawing mode, and supports easy random access to slides. There is an option to put up a footer giving the titles of the next and previous slides - useful for speakers who have a hard time remembering what's coming next. MagicPoint also offers a rehearsal mode where it continually shows how much of your allotted time has been used.

Generating an HTML version of a talk is a simple matter of running MagicPoint with the right command line options. There is, however, little flexibility in how that output is formatted.

MagicPoint is not a fast-moving project; the last release (1.10a) came out in June, 2003; 1.09 was released in September, 2001. In other words, not much is going on there. The lack of activity is somewhat surprising, given that there are many MagicPoint users out there. This tool has, evidently, reached the point where it is good enough; there is nothing so irritating that it inspires people to tear into the code. MagicPoint does have some bugs, some difficult features, and other issues - for example, fonts can make presentations hard to move between machines. It would be nice if this useful tool were to get some renewed developer attention.

(Those interested in MagicPoint input and output can see the editor's OLS 2004 talk and get a tarball with the sources and images that go with it.)

Pointless

Pointless is another markup-based presentation tool; it runs on most Linux and Unix systems. Your editor's first impression was that the Pointless developers are trying to build a system around a sort of object-oriented version of LaTeX. Pointless takes some getting used to, and is in an early stage of development, but it shows some real potential. Unfortunately, development appears to have stalled since the beginning of this year.

Users of Pointless end up typing in a lot of markup. Each bulleted line must be marked with =item, =subitem, etc. Plain text lines need =par, or are marked by a =begin-par/=end-par pair. Font and color changes follow a TeX-like style ({=small some-text}), and are a bit easier than the MagicPoint equivalents. Commands exist for importing images, setting tables, importing fonts, etc. There is also a macro definition capability which can be used isolate slide formatting decisions and cut down on the typing.

Pointless is written in Python, and it has made Python's module importing capability available to presentation files. The distribution comes with additional modules which can display EPS images or LaTeX source, create plots with gnuplot, or format source code.

There is one visual effect supported by pointless - a basic alpha fade out and in. It uses that effect everywhere, however, and it can make the rendering of slides quite slow. Commands exist for controlling the fader, but an attempt to use them (uncommenting the versions in an example presentation packaged with the source) resulted in Python tracebacks. Actually, crashing Pointless 0.5 is an easy thing to do in general.

Random access to slides during a presentation is not supported, and there is no drawing mode. Annoyingly, Pointless forces a pause before every bulleted item in each slide, requiring the speaker to lean on the space bar and watch each line fade in separately. This behavior can be changed by putting in =nostep - before every single line.

HTML output is supported. The mechanism is flexible; it works from templates and can substitute in many variable describing each slide. There is no "just make me some HTML" operation, however; the user must specify three different templates before Pointless will do the job.

Pointless has the potential to be come a highly-capable, extensible presentation system. For the moment, it remains - as stated on its web page - an alpha-phase project. Unless development picks up again, unfortunately, it is likely to remain there.

Summary

As always, there are some other projects which were not reviewed here, but which are worthy of mention:

• Agnubis is another attempt to create a GNOME presentation program. It would appear that development stalled in 2002, however, and the project, while having put up some screenshots, has never made an actual release. One of the authors posted a why agnubis did not succeed message in 2003.

• Criawips appears to be the current GNOME effort in this area. Version 0.0.7 was announced on September 9. Some screenshots are up, but little features like "creating and editing of slides" are yet to be implemented.

• Imposter is a standalone viewer for presentations made with OpenOffice.org.

• MinDia appears to be an active project. Its focus is on display of photography, however, rather than the creation of presentations.

• tpp is a markup-based presentation system which uses ncurses for its display. If you need to run presentations on a vt100 terminal, this system is for you.

So which package would a grumpy editor choose? On the graphical side, OpenOffice.org comes through as being more mature, and its "master page" mechanism can come in handy when one's employer is acquired and all of the page footers have to be changed at once. From the outside, however, KPresenter looks like a more vibrant, fast-moving project. Your editor also likes the feel of KPresenter better; OpenOffice, while being capable of almost anything, has always seemed unwieldy and aggravating to operate. OpenOffice should not be written off by any means, but KPresenter looks like it may be set to surpass it.

On the markup-based front, MagicPoint appears to be the only viable alternative at this point. Your editor will likely stick to it despite its slow-moving development and fairly primitive state. It has the features your editor really needs, and it does better at staying out of the way than any other system out there.

There seems to be a bit of a gap in the development of free presentation programs. The pointy-haired set, which wants sound effects, dancing bullet points, and easy pie charts, appears to be reasonably well served by the available graphical offerings. There is less available for those who prefer no-nonsense, text-centered presentations, quick talk preparation, easy display of code samples, and who are not afraid of a text editor. And the GNOME project, despite a few attempts (remember Achtung?) has yet to produce a presentation system of its own.

Projects in this area seem to have a high probability of stalling before reaching a stable state. Perhaps the problem is more difficult than it seems at the outset.

That said, the state of the art is clearly better than it has ever been; anybody wanting to do a presentation with free software has a few alternatives to choose from. There is no longer any need to face the embarrassment of being caught using PowerPoint at a Linux conference.

[As a postscript, your editor would like to let it be known that he has not forgotten his promise to complete the email client series with a look at terminal-based tools. That article is still in the works, and will show up, hopefully, before too long.]

Comments (56 posted)

Open Source Solaris?

As reported by News.com: Sun will release Solaris 10 under an open source license by the end of the year. Sun evidently wants to create a project around Solaris similar to the Fedora effort. There are numerous ways of viewing this announcement; in the absence of much in the way of real details, one might as well succumb to the temptation to apply a significant amount of imagination.

From a cynical viewpoint, one can argue that Sun is just acting from commercial desperation. By putting Solaris out there, the company hopes to attract attention, divert some developer and user interest from Linux, and, with luck, dump some of its development and maintenance load onto the community. Such a move would seem destined to failure; Sun's ability to "get" free software has been mixed at best in recent years, and the company is in no position to take a leadership position there now.

The paranoid among us wait, with trepidation, for Sun to specify a license for the code it is releasing. At best, they fear, Solaris will be managed like Java; source will be available, but the code will be managed with an iron hand and there will be no opportunity for a true community to come together around Solaris. In a worst-case scenario, the Solaris license will not only forbid any sort of cross-pollination with the truly free operating systems, but it will also "taint" any developer who looks at the Solaris code. A license which attempts to forbid the transfer of code, algorithms, techniques, etc. outside of Solaris could be fodder for the next round of unpleasant lawsuits. Remember that Solaris is based on SCO-owned code, Sun obtained options on SCO stock last year, and Sun dumped several million dollars into the SCO Group for "licensing fees" as well. The relationship between these two companies never has been explained in a satisfactory way.

The optimistic observer, instead, will hope that Solaris goes out with a GPL-compatible license. At that point, Solaris becomes another free Unix system, alongside the various BSD projects. Useful code in Solaris can be incorporated into other systems, and Solaris, too, can benefit from code and ideas found in the other free systems. Solaris users will know that their operating system can remain viable well into the future, regardless of what happens to Sun. And the free software community will be that much richer.

The gray-bearded True Unix People would still rather have the source for SunOS 4 (or even SunOS 3) and to heck with Solaris.

Until Sun tells us exactly what it plans to do, with an emphasis on which code will be released and under which license, it is hard to say with any certainty what the Solaris release will mean. Things could go in almost any direction. We're most curious to see what Sun comes up with; hopefully they will not make us wait too long before filling in the details.

Comments (4 posted)

What is KDE e.V. for?

Little is known or said about the KDE e.V., the registered non-profit organization that represents the KDE Project in legal and financial matters. Created to deal with various problems faced by a young free software project, the e.V. maintains a low profile and tries to merely protect the project, but is faced with demands for a greater role, as well as accusations of it being too closed. This article sets out to disambiguate the e.V.'s role, and what it means for KDE contributors and the wider free software community, from the point of view of a writer who works with the KDE Project but who is neither a member of the KDE e.V. nor a spokesperson for the KDE e.V. in any way.

Since the KDE e.V.'s pages on the KDE web site are relatively uninformative, I took the opportunity to talk to the Treasurer, Mirko Böhm, while attending the KDE World Summit "aKademy". He began by explaining the history of the organization. It started with three people in 1996 to solve two problems faced by the KDE Project: the need for legal validity when taking donations, and the concerns about the Qt licensing model that, at the time, wasn't Free and could have seriously damaged KDE. To cut a long story short, by late 1997, some German members of the project registered the KDE e.V. with the German Association Registry. In 1998 the KDE e.V. and Trolltech created the KDE Free Qt Foundation whose purpose was "to secure the availability of the Qt toolkit for the development of Free Software".

So from its start the key goals of KDE e.V. were to provide legal and financial representation for the project. But it is more proactive than those simple aims suggest. They provide an avenue for donations, they help promotion efforts, they organize conferences, and just as Linus Torvalds registered the trademark for Linux, so the KDE e.V. took control of the KDE trademark, to protect and promote the identity of the project. For KDE contributors, this means that they can use the legal and financial backing of the KDE e.V. to pursue trademark disputes. For the wider world this means that the KDE Project can force you to remove references to their trademarks from your work from them if they don't like it. Of course the KDE e.V. only intends to attack those who seek to damage the KDE Project through trademark infringement - it isn't going to stop people saying their work is a KDE application for the sake of it - but with this power comes the need for clarity regarding who is responsible and accountable.

Aware of the problems this might cause in a community based upon individual and community freedom, KDE e.V. claims to operate as an open membership organization. Rather than being run by companies and sponsors, as many other similar organizations are, the KDE e.V. is controlled by contributing members (i.e. contributors, documenters, artists, etc.). The idea is that the organization is run for free software contributors by free software contributors. Yet the membership process is still not entirely open, requiring that one existing member nominate you, and two further members support your nomination, which the Board of Directors then accepts. Enthusiastic users who feel they have a stake in the KDE e.V.'s decisions are excluded, as may be unpopular contributors. Furthermore the membership mailing list is closed, as are membership meetings, meaning that the free software community can only learn of the proceedings of the KDE e.V. through officially sanctioned channels.

For Rob Kaper, a KDE contributor who claims his views are not uncommon in the community, these closed channels are not always necessary nor useful. Whilst he recognizes that some matters such as financial reports should be kept private, he told me that the KDE e.V. membership should be calling "for a distinction between truly private matters and the aspects of true open source development". In particular he objects to the private-by-default membership mailing list, subscription moderated development mailing lists (he gave the example of khtml-devel) and the closed KDE.News editors, kde-security and kde-packager mailing lists. He sees a trend that he told me "is largely being ignored by the eV membership".'

Both the KDE e.V. Board of Directors, who are elected by the membership with terms of three years, and the membership itself might well reject some of these claims. Each decision to close an area of the project from the public is made by the contributors concerned, not the KDE e.V., and so the closed areas represent the concerns of the contributors. Of course Kaper would contend that contributors should be making things more open, not more closed, but then that becomes a separate matter of how free software projects manage themselves.

As Mirko pointed out to me, it isn't the place of the KDE e.V. to dictate how development and PR efforts ought to be conducted. One of the guiding principles of the KDE e.V. is to separate politics from development, although Mirko acknowledged that this isn't always possible. In this year's membership meeting at aKademy, for example, the membership voted to have the Board of Directors adopt a position on software patents that will allow contributors to stick to their work without worrying that KDE is sitting on the fence on such a crucial issue. And in the matter of closed mailing lists, whilst the e.V. membership can discuss the issue, it is more a matter of pragmatism. For Kaper though "the e.V. should protect KDE from efforts to control that kind of free flow of information", which "it can only do ... when it adopts more open policies itself". Doing this would mean a major expansion in the scope and power of the e.V. over contributors.

These minor disputes put the KDE e.V. in an awkward position. It wants to leave the project to develop according to the regulation of the GPL and their policy of letting the best code decide. Yet there seem to be issues where consensus will not arise naturally, where the project requires a space in which these issues can be debated and consensus can be built. When I asked Mirko about the future of the organization, he admitted that they don't have a clear idea of how it might evolve - that is up to the membership. Whether it is appropriate that the KDE e.V. expand its current role beyond that of protecting and promoting the project is undecided, as is whether or not its current activities and policies properly fulfill that role.

For KDE contributors it is a debate that needs to be engaged, and one that will hopefully result in a democratic vision of the organization's future. All contributors should understand and be part of that process. For KDE users and the wider free software community there is little scope for input, except through public debate that might influence the KDE e.V. membership. It is nonetheless an interesting experiment in running a formal entity that can represent a fairly anarchic community project, and so we will continue to benefit from their experiences.

Comments (4 posted)