Keywords: ohp, lecture, classroom, html, conversion
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:
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!
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 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:
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
Dept. Information Technology
La Trobe University, Bendigo
PO Box 199
N.A.WEB 96 - The Second International North America World Wide Web Conference http://www.unb.ca/web/wwwdev/ University of New Brunswick.