Creating Presentations with MagicPoint

This article started as a review of the interesting “MagicPoint” presentation package for UNIX/X11 systems, but ended up discussing some wider themes as well. I talk about various alternatives to Microsoft’s PowerPoint, a completely new paradigm for creating presentations, and touch on some design issues for an improved version of MagicPoint too.

Background: a positive experience of Markup Languages

I use LaTeX for almost all my text documents (except for web pages), including letters and so on. Naturally I became interested in using LaTeX for presentation slides as well, but here I ran into difficulties. It was possible, with a carefully concocted “paper size” to fit my screen dimensions, and a dvi or postscript viewer in fullscreen mode for giving the presentation. However, I had to change the settings when I switched to a different display (a lower resolution laptop) and the font support wasn’t great. In general it was an uphill struggle because of LaTeX’s assumption that the result is going to be printed out on a particular size of paper rather than viewed on-screen. I also considered HTML, but that wasn’t ideal either.

I did give several LaTeX presentations though, and I really liked editing my slides in one big text file. I could grep and search-and-replace (formatting as well as content), readily cut-and-paste parts or groups of slides, include comments, reuse material from other talks, and view and edit several slides at once (some features in PowerPoint-like packages such as “outline view” come close to this, but aren’t as fast).

LaTeX made it possible to get the content right before worrying about formatting at all. Even though formatting ultimately does matter where presentations are concerned, it doesn’t mean one shouldn’t think hard about content too. In a WYSIWYG package the formatting is taking some of your concentration from the moment you start typing.

If you use an integrated office suite presentation package, you have to adopt new and probably inferior tools for text entry and editing. With LaTeX I can employ my comfortably customised version of nedit which I am extremely productive with (obviously others will prefer emacs or whatever, the point is you can use your editor of choice).

I also suspect the learning curve for a non-WYSIWYG package isn’t as steep as one might expect. Although some training is necessary, many people are happy with basic LaTeX after an hour or two of explanation – MagicPoint is the same but easier. MS Office gives users the impression they know how to use it without learning anything in advance, which may or may not be a good thing! It’s probably easier to learn how to use PowerPoint than it is to give a talk worth listening to.

A frustrating experience with office suites

Being a heavy UNIX user, I usually don’t have a Windows machine available to run PowerPoint (besides, switching OS is inconvenient). Furthermore I can’t afford to buy MS Office; I’m never sure if our site license covers it, and don’t want to risk using unlicensed software.

As an aside, a lot of people seem to assume that MS Office and Windows do not cost anything beyond the price of the computer, since so often somebody (manufacturer, sysadmin, naive user or software pirate) has already installed them. In reality it isn’t free, moreover it’s one of the most expensive pieces of mass-market software available.

Although PowerPoint was therefore not available, I always assumed I “should” be learning and using “proper” presentation programs, and hence experimented with some similar software which I could obtain. Repeatedly I got some way through the creation of a presentation then gave up in frustration over some feature or bug in the program, exported my work to plain text and went back to LaTeX. In this way I tried and failed with PowerPoint alternatives over the course of several years.

Initially I thought my failure must be because the alternatives (such as kpresenter for example) weren’t as good as MS Office. They certainly were less polished and a lot less stable. To some extent this is still true today; PowerPoint is outstandingly good software, but the gap has closed. In particular StarOffice 6.0 Beta and recent OpenOffice snapshots do a pretty good job.

I then realised that although the cheaper alternatives were now less buggy, the real problem was that I didn’t particularly like the WYSYWIG approach to creating presentations. I wanted the benefits of my markup language back!

The other reason I felt PowerPoint (or StarImpress etc) to be unsatisfactory was that after hours of careful work I ended up with my information locked in a dedicated file format (the StarOffice format is at least open and XML-based, whereas the PowerPoint format isn’t disclosed). A package like LaTeX keeps your data in live, useful text format; it’s not write-only.

So, what other text-based markup languages are available for writing presentations, and how well do traditional UNIX methods carry over to a graphical office task? It turns out there is a program called MagicPoint which does the trick, and it works very well indeed.

Introducing MagicPoint

MagicPoint is a markup language presentation tool which runs on systems with X11. It isn’t a huge package; it’s quite simple, with a fairly restricted feature set. On the other hand, it certainly is mature enough to use for real work now.

The user creates their presentation in a text file, then runs the mgp program with the file specified as an argument. “mgp” interprets it and displays the presentation, a bit like a combination of LaTeX and xdvi in one.

Example

Here’s a sample extract from a MagicPoint presentation:

   %page
   %back "black"
   This is the slide title
   %fore "yellow", center, size 8
   Some centred information
   on two lines
   %fore "white", size 6

      First point in bullet list
      Second point
         First point in sub-list

Notice that directives have to start a line, and all begin with the percent sign. When displayed the tab-indented lines are automatically converted to bullet points; everything else is presented literally. Vertical spacing is done with blank lines and a new slide is started with the %page directive.

Document preamble

A MagicPoint document typically starts with a preamble containing global directives which define names for frequently used fonts, customise the header and the way slide titles are displayed, then set up default font sizes, colours and backgrounds. It also specifies the type of bullet marks to use and the amount of indentation at each level in a nested list.

Here’s an example:

   %deffont "standard"   xfont "arial-medium"
   %deffont "typewriter" xfont "courier new"

   %default 1 leftfill, size 2, fore "white", back "black", font "thick"
   %default 2 size 7, center, vgap 30, prefix " "
   %default 3 size 2, leftfill, bar "gray70", vgap 200
   %default 4 size 6, fore "white", vgap 50, prefix "   ", font "standard"

   %tab 1 size 6, vgap 60, prefix "   ", icon arc "yellow" 50
   %tab 2 size 5, vgap 40, prefix "          ", icon arc "yellow" 40
   %tab 3 size 4, vgap 40, prefix "                ", icon box "yellow" 20

   %default 1 bgrad

After that it’s plain sailing; most of what you type is the actual text, the markup is rare and unintrusive (just like most LaTeX documents).

What’s good

The user interface of the actual viewer is very good. It scales effortlessly to any size window or to full-screen with the window manager decor removed and has lots of mouse and keyboard control options. It’s really good at all the things that the Latex + ghostview/xdvi combinations and web browsers do badly.

The font support is comprehensive; no matter how your X server is configured you should be able to get good looking scalable fonts in MagicPoint. Image file support is also good, including png (so much nicer than LaTeX’s EPS imports!) Measurements can sensibly be specified as percentages of the screen or image size, and it is possible to tell MagicPoint which resolution you designed an image for, from which it can scale appropriately.

As one would hope, creating slides is extremely fast, for example I could cut and paste templates and data into my text editor much more rapidly than I could with the mouse in the PowerPoint GUI. I was also focussing on content again, which saves hours if not days that would otherwise be wasted creating PowerPoint slides.

A couple of simple wipes and transitions between slides are provided and there is straightforward support for background colours and images. Surprisingly, MagicPoint puts quite a few powerful dynamic effects at your disposal, such as pausing to unveil points gradually, flying new text in, displaying animations and even arbitrary X11 applications embedded in a slide (although I personally avoid such distractions wherever possible in my own presentations).

In addition to displaying on-screen, MagicPoint can output HTML or Postscript slides. The HTML generation works by creating JPEG images of each slide and an index page with thumbnails. I found this to be an excellent feature, although it would be nice if the user could specify the compression level.

Previewing your presentation

The ability to preview the final output is vital when you are using a markup language system. For example in LaTeX it would be common to keep an xdvi window open, and run LaTeX quite frequently to keep an eye on the results (more so in the later finishing stages than early content creation, of course).

With MagicPoint the edit-preview cycle is very fast, since mgp is really quick (considerably faster than any office application I’ve seen, even faster than xdvi, and a *lot* quicker than Postscript). If that isn’t enough the program can generate the next page whilst you are looking at the previous one, so even if you have a slow machine and need to scale lots of elaborate fonts for display on a 1600×1200 screen it’s always snappy.

Unfortunately MagicPoint often has trouble when you change a source file whilst it is running. If you are editing a slide in the middle of your presentation it would obviously be very cumbersome to restart the viewer and skip forward lots of slides each time you wanted to update the preview. I couldn’t find a redisplay command as such, but skipping back a slide and then forward again seems to trigger a file reload. Alas, this only works some of the time (changing the contents of a line was OK, adding or deleting lines to a slide triggered a core dump more often than not). This didn’t annoy me hugely but obviously needs attention in future releases.

Just add graphics

In MagicPoint there are no graphics commands (only text, colours, bullet points, horizontal bars and images). So you have to create diagrams in another package and include them as an image. In this sense MagicPoint is more of a “layout” package. This actually suits my presentation style very well, since I don’t generally have time for complicated overlaid graphics. I’m quite happy to create my diagrams in tgif (my preferred vector package – very fast in use), and of course others can use their personal favourite program.

On the other hand, it does make me slightly more reluctant to include diagrams – there’s the effort involved in firing up another package and saving the file. I would probably use more connecting arrows and so on if I could just add them straight onto the slides. Whether this is a good or a bad thing is for you to decide.

Some people may rightly complain that specifying coordinates and scale factors is slower than dragging and resizing a picture around in PowerPoint’s GUI. I guess my ideal presentation program would have an interactive image placement tool built into the viewer, and save coordinates specified in this way into an associated resource file (to avoid touching the main file, which should only be edited by the user). But now I’m dreaming…

DIY Macros

One feature MagicPoint lacks is a macro capability. Fortunately it is relatively easy to add one yourself by processing the text file with other utilities. I used the macro pre-processor “mpp”, which took about 20 minutes to install and master.

To give you an idea of how simple this can be, here’s a little Makefile which processes the source file talk.mgp.mpp to expand macros:

   talk.mgp: talk.mgp.mpp
      mpp talk.mgp.mpp

You can define and instantiate basic, unparametrised macros like this:

   #def foo bar
   #foo

For example, here is the definition and an expansion of a nice footer bar for each slide:

   #def footer
   {
   %size 4
   %font "italic"
   %area 100 2 0 90
   %bar "white" 100 0 100
   %area 50 8 0 92
   %image "logo.jpg" 0 45 70 0
   %area 50 7 50 93
   Put the talk title here
   }

   #footer

What’s bad

For simplicity, the MagicPoint syntax only allows directives to start a line, rather than intermingling directives and text. It is still possible to change font or colour part way through a line of output if you add the special “cont” (continue) directive, which instructs it to consume the surrounding newline characters. It does get pretty clumsy writing things like this though:

   %fore "cyan"
   The next word is
   %cont, fore "white"
   emphasised
   %cont, fore "cyan"
   in white; everything else is blue.

Some slightly more sophisticated parsing would solve the problem.

The PostScript output generator is quite poor and doesn’t really produce usable copy. Because it is separate from the on-screen display engine it lags behind, and there are lots of things it either can’t handle or formats completely differently (of course when printing handouts one would like a pretty close facsimile of the actual slides).

A related weakness is that a MagicPoint presentation can’t be displayed on a MS Windows machine (at least LaTeX output could in theory be presented with ghostview, and there’s no problem with HTML).

Irritatingly, despite the numerous ways of specifying image size, it doesn’t seem to be possible to scale an image to a given percentage width/height of the screen whilst preserving its aspect ratio (you can preserve the aspect ratio if you specify an absolute zoom factor or a percentage of the original image size, but then it doesn’t adapt correctly to different screen sizes). Perhaps I’m doing something wrong, but this turned out to be a big problem for presentations with more than a couple of images.

I had the occasional minor gripe, for example the helpful page number index which is displayed in the viewer when you press Ctrl always appears in a very small font, and there’s no way to include page numbers automatically in the slides themselves. The other major problems I encountered all relate to the “area” directive, which is enough of a minefield at present to warrant its own section…

Cutting edge: the area directive

MagicPoint 1.09 (the latest version) adds the very useful “area” feature, which changes the origin and restricts drawing to a rectangular part of the screen (in fact I’ve already used it in my footer example). The ability to add footers to each slide automatically was one of my key requirements, but I was only able to do it using areas combined with the external macro package (MagicPoint has explicit support for headers, but not for footers).

It’s unfortunate that the area directive wasn’t made a basic part of the program earlier (like frames in KWord), since at present it feels like a much needed but poorly integrated add-on. The critical problem is that scaling images doesn’t work properly in areas, presumably because the program tries to scale relative to the subrectangle and gets the wrong result. Font changes also don’t work too well in areas, although changing font just before invoking an area directive does successfully effect the text within the area.

The postscript converter, mgp2ps doesn’t work at all with areas yet, so you can’t use them in handouts. Also, a nice convenience feature which is missing is the ability to specify an area offset without a size (in which case it would be helpful if it extended to the edge of the screen).

Finally, one of the slide transition modes (number 1, which scrolls across horizontally) seems to be broken for me in 1.09. Since I needed the area directive as well I backed out the changes after consulting the source code for 1.08, to get a version with areas and working transition mode 1. I hope this will be resolved in time for the next version!

Conclusion

I think MagicPoint is great, and has a very promising future. It’s a surprising and innovative way to create presentations which makes a lot of sense in retrospect. I’ll certainly use it for my next presentation, and perhaps contribute some code to address a couple of the deficiencies I’ve pointed out in this article. I’m blown away by the usefulness of a markup language designed specifically for presentations, especially combined with such a slick X11 viewer.

Share this post:

Share on facebook
Share on twitter
Share on pinterest