Living without Windows!

by Jos Visser

Part 16: Hacking course material

Boring introduction :-)

The ardent follower of this series of articles knows by now that one of my major activities is teaching courses on a variety of subjects. Normally, these courses are taught at vendor (HP, SUN, Netscape c.s.) locations with vendor course material. However, ov er the years I have written a fair amount of course material myself on different subjects, ranging from the Internet, to Java, Unix and the year 2000, implementing a secure web server and Object Oriented Programming. When I started to develop courseware, I was foolish enough to contemplate doing that in Microsoft Word and PowerPoint. I even started out using Word/PPT; remember, this was way back in my bad old Windows days! This turned out to be a traumatic and painful experience. Suffice it to say that Word was not up to the task. It is remarkably bad at handling large documents, especially when this document contains a lot (and I mean a lot) of linked objects from another (in this case a PowerPoint) file. Something better was called for.
Now, around that time (way back when) I was spending time on a consultancy job in the Far North of the Netherlands. Now, for Canadian folks reading this, our Far North is not quite what your Far North is, but, in Dutch terms, it still is a desolate place. In this case: the city of Groningen. In the back of my mind, I had always known about the existence of TeX, but I had never gotten round to investigating or using it. This seemed to be the correct time to do so. I bought a couple of TeX (and LaTeX) books (in one of the finest bookstores north of Utrecht: Scholtens Wristers in hte centre of Groningen) and in the lonely evenings in my hotels, surrounded by millions of acres of wilderness (in Dutch terms, that is), I started playing with TeX to see if I could easily create big course books containing PowerPoint slides.

SideStep on TeX and LaTeX

Before I continue it might be worthwhile telling something about TeX and LaTeX. For a truly great introduction, and a whole load of related TeX resources, I would like to point to the web site of the TeX User Group.
TeX is a computer program for typesetting documents. It works on a structured input file that instructs TeX how to lay out pages and how to perform other important related tasks, such as making tables of contents and breaking off words. TeX is absolutely not What You See Is What You Get, you "program" your document, much like other document processors such as "troff" and DCF. Using native TeX you can do pretty low level type setting, probably not what you'd want in an average document. But, help is at hand: TeX understands a macro language and inventive folks have written gazillions of macro packages and styles over the years that help the hapless user creating documents at a much higher level. The macro package takes care of issuing the low level TeX instructions used to format the document. One of the most succesful TeX macro packages is LaTeX. Indeed, it has become so widely used that most people seem to use LaTeX without knowing that TeX actually underlies it!
Using LaTex, a document might look like this:

\section{De conferentie}
\subsection{Introductie}
%----------------------
De feitelijke organisatie van de conferentie gebeurt door twee ``instanties'':
\begin{description}
\item[De programmacommissie]
is samengesteld uit leden van de NLUUG. Zij hebben tot
taak om het programma samen te stellen en sprekers te werven.
\item[Het bureau]
verzorgt de co\"{o}rdinatie van de conferentievoorbereidingen en het grootste
gedeelte van de conferentie zelf.
\end{description}

(This piece comes from an actual paper I wrote very recently for a session called "Delivering Quality at NLUUG Conferences")
As you can see, you concern yourself mostly with the logical structure of your document, letting (La)TeX taking care of the rest.
In order to print or preview your document, you have to run the TeX formatter program on your document. TeX ponders on its input, and writes out a so called DVI file. DVI stands for "Device Independent"; the brilliancy of it being that the DVI file contains the physical layout instructions for each page, but still not in a format suited to be directly processed by an output device! To get an idea of what a TeX run looks like, click here.
To actually view or print the DVI file, you use a special program to convert the DVI file to a format suitable for processing by a specific output device. Scores of programs exist to convert DVI to PostScript (dvips), to HP LaserJet PCL (dvilj), to Epson print codes (dvieps), to ASCII (dvi2tty), or to an X-Windows (xdvi) or MS-Windows (dviwin) display. (For the TeX knowledgeable out there, I deliberately skip over MetaFont font generation not to complicate matters too much at this introductory level). For instance, to convert a DVI file to PostScript, you run "dvips myfile.dvi" to generate "myfile.ps" (example). PostScript is quite a nice format to convert to, because once you have PostScript you can use the many facilities of GhostScript to display and/or print the file.
All in all, it is pretty cool. Oh, and by the way, TeX is pronounced as rhyming with "blecch".

I start using LaTeX under MS-Windows

So, way back when I started investigating TeX, I was looking for an efficient and pleasant way to create big course book, using external overhead slided made with PowerPoint. The reason for the last being that I liked to use PowerPoint, and it gave me an easy way to project the slides straight from my laptop using a beamer. (For the TeX knowledgeable, yes I do know about SliTeX but I still preferred PowerPoint for a number of reasons).Using LaTeX to create the course books is in itself a piece of cake. Obviously, you have to master the LaTeX language, but there exist several first class books on that topic. In addition, I can recommend the O'Reilly book "Making TeX Work"; it is not about the TeX or LaTeX instructions, but on almost every adjacent topic such as using fonts, printing documents, including figures, TeX editors and national language considerations.
From the outset it was clear to me that the real challenge would be including the PowerPoint slides. In my humble opinion, TeX is remarkably bad at including external figures in common formats such as GIF or JPG. I have as yet not come across a nice standard feature to achieve this; quite a pity since GIF and JPEG are the de-facto graphic file formats for images of all sorts. There exist a number of macro packages that you can use to create figures using TeX's primitive drawing instructions. However, that did not really suit my needs. Hmm, some thinking was called for....
After careful study of the various TeX books and document files I decided that the road ahead was to use a TeX "escape" mechanism called "\special". In a TeX source, one can embed \special commands. The TeX type setting engine does not interpret these \special commands, but instead copies them straight into the output DVI file. It is up to the DVI printing or previewing tool to interpret these \special commands. Various DVI viewers implement \special features to perform specific non-standard functions, such as including pictures! Using \special, you bind your (La)TeX document to a specific DVI viewer, thereby foregoing the device independent nature of the format.
One of the most popular (and feature-full) DVI previewing and printing programs for the Windows platform is the "DviWin" program. It interprets DVI files, shows them onscreen and prints them using the Windows device drivers, thereby being capable of printing DVI files to any Windows supported output device. As it turned out, DviWin understands a range of \special instructions that render images in various common formats, amongst which BMP and the Microsoft proprietary Windows Meta File (WMF) standard. Especially the last option drew my attention back then. WMF is not a bit-mapped format, but instead, a WMF file contains drawing instructions that follow the Windows API quite closely. In the Windows API there are functions for interpreting and thereby rendering a WMF file (also called replaying it). Because it is not bit mapped, it is quite easy to scale (enlarge or reduce) the image at rendering time without loss of quality.
As PowerPoint is capable of exporting a slide as a WMF file, I devised the following solution:

Create a presentation in PowerPoint

Export each slide as a WMF file (I even wrote some PowerPoint macro's in Visual Basic for Application to assist me with that).

Create a course book in LaTeX, using the DviWin-specific"\special" commands to include the slides.

Run LaTeX on the source files.

Use DviWin to preview and print the course book.

To assist me in the process I had written two LaTeX macros to easily incorporate the slides in the course book:
\newcommand{\slidedir}[1]{
\edef\incdir{#1}
}
\edef\incdir{.}
%------------------------------------------------------------------------
\newcommand{\slide}[2]{
\newpage
\special{isoscale \incdir/#2,\the\hsize 120mm}
\section{#1}
\hrule
\vskip 100mm
\hrule
\vskip 5mm
\textbf{Notities}
\vskip 2mm
}
Using these macros, a piece of course book might look like this:
%------------------------------------------------------------------------
\slide{The year 2000 problem}{0020-problem.wmf}
Unless you spent the last two years on a deserted island, you are probably
aware of the Y2K problem and what it comprises. It mainly boils down to three
different problems:
(Taken from a short tutorial on "Unix and the Year 2000")
On paper, this piece looked like this. (Due to various graphics problems this picture does not look great, but believe me, on paper it does!)
All in all I was pretty satisfied with this solution. I have used it to create BIG course books (over 400 pages, containing almost as many slides). And I was pleased to find out that LaTeX and DviWin are quite capable of handling these volumes :-).

Living without Windows

And then I started Living Without Windows. Things should go easier now, shouldn't it?
I soon ran into the following problems (issues, challenges):

DviWin is obviously not supported under Linux.

Windows Meta File format files are obviously not supported under Linux.

I now had to create presentations using Applix Presents

Well, challenges exist to be overcome! So I methodically started attacking. Further study soon learned me that the solution probably lied in Encapsulated PostScript.

Sidestep: PS and EPS (and some LaTeX)

Some explanation might be called for. PostScript is the page description language of choice in Unix systems. It is a proprietary standard from Adobe that is nevertheless widely supported by a whole load of systems, software and printers. A PostScript file contains an exact description on how one or more pages are to be presented or printed. It is fairly low-level, logical document niceties such as a table of contents, a title and footers all have to be taken care of. Like WMF, PostScript is not a bit-mapped image of a page, but more specifically a set of instructions that have to be followed by a PostScript interpreter in order to create the bit-mapped image on a page or on a display. A bit of PostScript looks like this:
pop
/BuildChar
{ 0 begin
     /char exch def
     /fontdict exch def
     /charname fontdict /Encoding get char get def
     /charinfo fontdict /CharData get charname get def
     /wx charinfo 0 get def
     /charbbox charinfo 1 4 getinterval def
     wx 0 charbbox aload pop setcachedevice
     charinfo 5 get charinfo 6 get true
     fontdict /imagemaskmatrix get
       dup 4 charinfo 7 get put
       dup 5 charinfo 8 get put
     charinfo 9 1 getinterval cvx
     imagemask
   end
   } def
As you see, a PostScript file looks like a sort of program that has to be interpreted in order to create the page image. The two most common PostScript interpreters are:

PostScript printers. They can be sent a PostScript file and barf out the pages. Very handy!

GhostScript. An open source PostScript interpreter that can display PostScript files on the screen and convert them to a variety of other formats such as PDF and PCL.

As you might remember from a previous section in this article, the "dvips" program can be used to create PostScript from a TeX DVI file.
Another concept in this space is that of "Encapsulated PostScript". A PostScript file contains one or more complete pages. In contrast, an Encapsulated PostScript (EPS) file contains a page element such as an image or a picture. Basically, an EPS file describes one page in PostScript, but it contains one extra parameter, the BoundingBox, which describes which part of that page (in 4 coordinates, top left and bottom right) forms the page element. Real Hackers can convert any PostScript file to an EPS file by adding the BoundingBox comment manually. Oh yes, and to state the obvious, PostScript files can include EPS files.
If you want to know more about PostScript, you could probably do worse then check here.

The outline of a solution

Of course I knew that PostScript and EPS are quite common in the Unix world. My "research" soon showed that "dvips" contains \special commands to include EPS files in its PostScript output, and that LaTeX contains a set of macros (as part of the "epsfig" style) to generate these "dvips" \special commands.
So I came up with the following plan for (re-)creating my course material under Linux:

Use Applix Presents to create presentations (or convert them from PowerPoint)

Export each slide as an EPS file

Change my "\slide" LaTeX macros to include the EPS file as the slide part of a page.

Use "dvips" to generate a PostScript file from the DVI file.

And then either print that PostScript file or view/convert it using GhostScript. Being a methodical person, I started with the first point of order: creating presentations in Applix Presents and exporting them to EPS.

Applix Presents

In my new non-Windows life, I use the ApplixWare Office suite for Linux for all my office tasks, amongst which creating overhead presentations. Applix Presents, like all other Applix office tools, takes a bit of getting used to, but once you've got the hang of it, it more than suffices for my needs. After some experimenting, and reading the manuals, I have created something of a template that I can use to give all my presentations the same look.
For my course books, I need to have each slide as an EPS file. This proved to be a bit more problematic than it at first seemed. Presents has an export facility that can export one or more slides to another graphics file format. EPS is one of the supported export formats, so naturally my first shot was to use File->Export. It did not work. I messed around a bit with the various options, but unfortunately, I was never able to succesfully export a slide as EPS using ApplixWare's built-in features. After selecting the File->Export menu command, the hard disk rattles a bit, the mouse pointer changes into a small wristwatch, and after some time an error window containing a remarkably vague error message pops up.
Given the fact that PostScript and Encapsulated PostScript are almost the same (remember, EPS contains BoundingBox information), I then chose the path of exporting (actually printing) a slide to PostScript in order to see if I could turn it into EPS using a small tool or program. Printing something to PostScript is a breeze in Applix, it is one of the preferred output formats. Once you have a file in PostScript, there are basically two ways in which you can turn it into EPS:

Use an editor to manually add the BoudingBox info.

Run a convertor tool to do the trick for you.

Manually adding the BoundingBox info is quite easy, once you know how to calculate the four BoundingBox parameters. In my case, each slide is a full page and thus has the same BoundingBox. Inserting that BoundingBox with a small Perl script would be trivial. I did look at the other options as well though. GhostScript comes with a tool called "ps2epsi" which, as you might imagine, converts PostScript to Encapsulated PostScript. ImageMagick comes with a "convert" program which can read in a graphics file (in a whole load of different formats), manipulate it (rotate, resize et cetera), and write it out (again to a whole load of different formats). In my experience, "ps2epsi" works fine; "convert" works fine as well, but has one major drawback, it converts the PostScript to a bit mapped image and generates EPS that contains the bitmap. This makes "convert" unusable for me, because I like to have the more native PS "vector" instructions so that it becomes easy to scale it.
Fortunately, a closer inspection of the LaTeX EPS features quite easily solved my problems. It turned out that the LaTeX "\epsfig" command allows one to specify the BoundingBox of an included PostScript file externally! In that case, the included (E)PS file does not need to contain a BoundingBox! Hurrah! This means that I can include the slides directly in my course books.
The one problem still open was that I needed to export each slide as a separate PostScript file. Obviously, this can be done manually: tiresome, cumbersome and not really what I would like. Fortunately, like many office suites, Applix supports a programming environment in which you can write macros to automate tasks or develop small programs. Applix's features is (unfortunately) called ELF. I had never written ELF, but now was apparantly the time to learn. I delved into the extensive on-line help on the subjects, and wrote the following macro:
macro volgende
    var lp,i
    gr_last_page@()
    lp=gr_get_page@()
    gr_first_page@()
    for i=1 to lp
        gr_print@("",TRUE,1,FALSE,FALSE,i,i,"/tmp/slide"++i++".ps",
            FALSE,"PostScript",NULL,0)
        if i<lp then gr_next_page@()
    next i
endmacro

I can run the macro (which for reasons unbeknown to even me is called "volgende") from withing Applix Presents. It enumerates all the slides in the presentation and prints each to a file called "slidexxx.ps" in "/tmp".

Redoing my LaTeX macros

After having sorted that out, I needed to rewrite my "\slide" macro to incorporate the slides from a PostScript file. Here it is:

\newcommand{\slide}[2]{
\newpage
\section{#1}
\hrule
\epsfig{figure=\incdir/#2,width=12cm,angle=270,
bbllx=0,bblly=0,bburx=791,bbury=611,clip=1}
\vskip -3cm
\hrule
\textbf{Notities}
\vskip 2mm
}
In this macro, I resize the slide to 12 cm wide and rotate it 270 degrees in order to change its orientation from landscape to portrait.

Finally

I am finally again able to create OSP course books using my preferred tool set: LaTeX. And, although I must say that I am getting used to this by now, it goes faster then before, and the results are better! As an added bonus, the "xdvi" previewer understands the same "\special" commands as "dvips". This means that I can preview my course books with slides included directly from the DVI file (example).

Last change: 24th May 1999 by moi