A Tool For Authoring OHP Presentations Using HTML

Philip Scott
La Trobe University, Bendigo

Teachers commonly provide course material on the World Wide Web in conjunction with presentation of the same material in a conventional classroom or lecture situation. This leads to a difficulty with format conversion - one format for the lecture, and another for the Web. Conversion is difficult enough, but maintaining consistency between the two formats can be even more difficult, as changes are made to the original document. One solution to this problem is to author the original document in HTML, and present it in the classroom using a browser and PC screen projection equipment. This can be effective, but many teaching rooms still are not equipped with suitable hardware. In particular, day-to-day classroom teaching often relies on the trusty old OHP. This can obviously be used to display the printed output from conventional browsers, but such output tends to be of inappropriate pointsize and document structure for the purpose. We have written a software utility which accepts a defined subset of HTML, and using some slightly modified interpretation rules generates high-quality PostScript(tm) output ready for use in an OHP environment. Despite some shortcomings our utility is now in regular daily use by a number of our teaching staff.

Keywords: ohp, lecture, classroom, html, conversion

The World Wide Web provides an ideal tool for distribution of teaching material to students in an academic environment. The preferred approach at Bendigo is one whereby lecture notes or outlines are available on the Web prior to presentation of the material in a conventional lecture situation. This is similarly true for tutorial and practical worksheets, sample programs and the like, where appropriate. In addition, most of our lecturers take the opportunity to use the Web to provide pointers to relevant external resources, and for day-to-day administrative announcements. In a very short period of time it has become an almost indispensable tool to many of us.

A difficult problem, confronted by anyone who has adopted the Web for these purposes is that of document conversion. This arises because courses are normally developed using "presentation graphics" software packges, of which the generic standard is now Microsoft Powerpoint(tm). They are able to be used for OHP or screen-based presentations equally well, and make preparation of attractive presentations almost trivially easy. Their popularity is well deserved. However, it is not obvious how lecture presentations developed using such software packages should be migrated to the Web. The alternatives appear to be:

  1. Convert the proprietory presentation graphics file into HTML, the language of the Web. The greatest benefit of taking this approach is that the resulting document has the "look and feel" of the Web. In addition, with a small of amount of extra effort, the author can add hypertext markup to the resulting HTML, introducing cross references, external links, and multimedia material. The potential therefore exists to create a far richer learning environment than merely distributing lecture material.

    The difficulty with converting from a proprietory format to HTML is that most conversion tools tend to produce results of varying, but generally poor, quality. Managing the conversion can also be very time consuming, although this depends to some extent on the quality of the tools employed. Finally, conversion of inline graphic images seems to take a disproportionate amount of time. Nevertheless, some lecturers report that once they get a conversion system "just right", they can get the time and effort down to satisfactory levels.

    The presenter's problems with document conversion are not finished when the conversion is done, however. He or she now has two copies of the presentation in two formats. Worse, the "derived" copy may have had changes, such as the hyperlinks mentioned above, which do not appear in the original. When changes are made to the original document, as they invariably are as courses develop over time, the "edits" have to be made to the original and to the HTML version. Attempting to always keep two versions of the same document consistent can become a real headache!

  2. An entirely different approach, and one which is commonly seen, is to simply make the lecture material available in the original presentation graphics file format. The student must install a suitable "viewer", and configure his or her browser to use it. In this model, the Web is being used simply as a "file distribution" medium. Its obvious advantage is that the work of the lecturer is minimised. It also preserves the "artistic integrity" of a lecture presentation, a fact which may be highly important in some disciplines.

    Its disadvantages include the fact that much of the power of the Web to enhance learning by the addition of hypertext links is forgone. Where material is presented in HTML students can browse at their leisure, skipping material that they understand and following links to alternative explanations of more difficult concepts. In this model they are forced into a linear trip through the lecture. Furthermore, depending on the capability of the viewer software, the student may see the lecture at the same scale as it appeared in the lecture (with the same fonts and pointsizes for example) which may be inappropriate for personal viewing.

The difficulties of both of the above approaches have led to new techniques. For the past year or so, some of us have been preparing our original lecture material in HTML instead of using presentation graphics software packages. This is made easier by the current generation of Web "authoring tools" which have largely removed the need to write HTML. To present the material in a lecture environment, an ordinary browser such as Netscape(tm) can be used in conjunction with one of the varieties of screen projection hardware and a suitably networked PC or Mac. We have used this approach on our campus in the lecture rooms which have such facilities.

The use of a Web browser as a presentation graphics tool has a few disadvantages. In general the HTML must be authored in such a way that scrolling is not used to display the presentation. Our students, and others, report that this is very distracting. Best classroom practice seems to be to use a configurable browser, and set it up with a specified (large) pointsize for text, with appropriately sized inline graphic images such that each HTML "page" is displayed in one full screen of the browser. HTML pages can then have linking "forward" and "back" buttons. In this way, the presentation approximates the results obtained with conventional packages such as Powerpoint. In reality, this is simply cajoling the browser into a role it was not designed for, although results can certainly be very good.

Our greatest problem with this approach is, however, not the quality of results obtained. It is the simple fact that the majority of the teaching rooms which we use on a day-to-day basis do not have suitable screen projection facilities. In fact, the only teaching aid which we can depend upon having in every classroom is the humble Over Head Projector, or OHP. Even if we prepare our material in HTML, we have to be able to use these basic facilities at some time. Now it is not possible with current browsers, to sufficiently customise their printed output for this purpose. What is required is a software utility which can accept as input an HTML document, and which will generate as output a PostScript(tm) document which can be printed onto OHP transparencies and immediately used in a classroom situation. We have built a prototype of such a utility.

We call our utility "ohpmlps". It takes as input an HTML file and generates a PostScript(tm) file as output. In designing ohpmlps, we were aware that the requirements for an OHP-based presentation were somewhat different from those where the document was simply designed to be browsed. In particular, an OHP presentation must, of necessity, include the idea of a "new slide" or, in other words, page breaks. Because HTML does not include markup for this, we were faced wth a choice:

  1. We could define a new markup along the lines of the existing <P> type, such as <pagebreak>, which should be ignored by other browsers (browsers are supposed to ignore markup they don't understand). In the end, we decided against this approach. We felt that what the world needs least of all right now is yet another browser-proprietory addition to HTML - the big browser companies are already doing enough of this for everyone. We felt that there was intrinsic merit in writing course material in standard HTML.
  2. Instead we decided to simply interpret some of the standard HTML markups in specific ways. The markups to which we assigned special meanings are:
    This would normally create a "horizontal rule" in the document. We interpret this markup as forcing a page break, or new slide.
    <H1>Some Text</H1>
    Normally a "Heading 1", the largest heading in a document, we interpret this as the title of a "slide". Therefore, a slide consists of a <H1> markup, some ordinary HTML which is interpreted as the body of the slide, followed by an <HR> markup. A presentation is simply a sequence of any number of slides.
    <TITLE>Some Text</TITLE>
    Our software expects to see, somewhere before the first <H1> in a presentation, a <TITLE> markup. This is placed at the bottom of each page, in the same way as many authors do with ordinary presentation packages.
Otherwise our proptotype accepts pretty much all of ordinary HTML and generates output as one would expect for OHP use. We generate 36 pt Helvetica-Bold for slide titles, and either 18 pt or 24 pt Helvetica-Bold for body text. The only emphasis markups which have any effect are <EM>, <STRONG> and <I> which all do the same thing; they change the text style to Bold-Italic instead of just Bold. Some other text types, such as <TT> and <KBD> were being added as this paper was being written; our next project is to get <PRE> working. The three list types <UL> (unnumbered list), <OL> (ordered list) and <DL> (description list) are all implemented, although nested lists don't work yet.

The current version of our software handles inline GIF images so long as they are stored in the current directory. We use the NetPBM libraries to convert GIFs into PostScript EPSF files which are inserted into the output file. We have, however, been rather disappointed with the results obtained. The GIF files we have worked with have generated rather "chunky" graphics when printed on a laser printer, and we are looking at some ways to improve their quality. We also provide a facility whereby a PostScript EPSF file can be specified on the command line, and included into every slide. We felt this was preferable to using the < ... BG="file.gif"> markup for this purpose, but we are open to discussion.

A fair bit of HTML is ignored by our software partly because, quite simply, we have not figured out how to parse it yet. In order to make a virtue out of necessity, we simply define a basic subset of HTML 1.0 (which is really all that is needed for OHP presentations in any case) which we have called OHPML, hence the name of our software, ohpmlps. In addition to the rules given above, our software ignores any markup pertaining to hyperlinks (<A ...> markups). It also ignores <H2> through to <H6> headings, rendering them as ordinary text. At present, the PostScript output makes some assumptions about the size of a transparency, using A4 paper dimensions. A later revision will permit customisable output.

The current version of ohpmlps is written for the Unix platform using the standard tools lex and yacc, with supporting code in C. In attempting to write such a utility, we were surprised at the difficulty we encountered in parsing HTML. It seems that yacc may have been a bad choice of tool, but since none of us involved in the project had significant experience in compiler and parser technology, we were not to know this. Early in 1996, we became aware of a piece of software with some similarity to ours, called "html2ps". This software is written in Perl, and we may attempt to use it as the basis of our next version.

In conclusion, we believe our prototype has established the feasibility of our approach to using the Web to make available teaching material, written in HTML, where the same material is also presented in a conventional classroom setting using basic OHP technology. The current version of our software has many shortcomings, but is nevertheless in everyday use by several lecturers at Bendigo. We see many ways in which our software could be developed, and we also believe that the established browser manufacturers could incorporate customisable, configurable printing into their products to achieve the same results as our software does. We are very interested to discuss our ideas on interpreting HTML for specific application purposes, as detailed in this paper.

A current version of the ohpmlps software (source code, and with very little documentation) can be downloaded from the Web page http://ironbark.bendigo.latrobe.edu.au/staff/pscott/ohpmlps/ohpmlps.html

Updates, changes and revisions to this paper may be found at: http://ironbark.bendigo.latrobe.edu.au/staff/pscott/ohpmlps/Paper.html

Philip Scott
Dept. Information Technology
La Trobe University, Bendigo
PO Box 199
Bendigo 3550
Email: P.Scott@latrobe.edu.au

Phillip Scott 1996. The author assigns to the University of New Brunswick and other educational and non-profit institutions a non exclusive license to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author grants a non-exclusive license to the University of New Brunswick to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers, and for the document to be published on mirrors on the World Wide Web. Any other usage is prohibited without the express permission of the author.

N.A.WEB 96 - The Second International North America World Wide Web Conference http://www.unb.ca/web/wwwdev/ University of New Brunswick.