1 Introduction

There are many circumstances in which print (rather than electronic) documents need to be prepared for visually impaired people (VIPs). Often the documents have to be produced on an ad-hoc basis by people with little training in the production of documents for this client group. Examples of these circumstances include education (especially where a VIP is in an integrated educational environment); the workplace (where a VIP must be given access to a wide range of documents); and where companies and organisations have to communicate with their customers and clients some of whom may have a visual impairment. The work we describe was motivated by the last case. The Guide Dogs for the Blind Association (GDBA) in the United Kingdom has a policy of communication with its clients in their preferred format, which may be large print, speech (on cassette tape) or Braille.

In this paper we describe a suite of tools that can be integrated with a standard word processing application (Microsoft Word) that allows non-specialist staff to produce documents in large print, speech or Braille directly from Word. The document is produced in the same way as it would be for a sighted reader (indeed it may well be identical to that produced for sighted people). The word–processor operator then selects the appropriate menu item to coverts the document into large print, speech or Braille and, provided that the operator has access to the appropriate hardware, the appropriately formatted document will be produced without recourse to specialist staff.

The paper is organised as follows. Firstly we describe the technical architecture of the tools. We then describe each of the tools that produce documents in each of the three formats (speech, Braille and large print). We conclude the paper by discussing the current status of the work and indicate how the tools have been adapted to produce applications that can be used in other contexts.

2 The Architecture of the Tools

The tools are designed to be used with Microsoft Word. This decision has been made for two reasons. Firstly, Word is very widely used and so, by providing tools for this application, we should maximise their potential use. Secondly, Word provides a convenient means to be able to access, alter and create documents under software control, through a mechanism called the Word Object Model. However, we believe that our approach could be used for other word processors.

The Word Object Model allows Word to be controlled by software by exposing its internal structure to other programs. This structure can be both viewed and controlled by another program. So, for example, another program can examine and change the currently loaded document. This would enable another program to, for example, step through the document, identify if a word was bold, and then turn it into italics. In addition, Word operations such as loading and saving documents can also be executed.

There are two major techniques for accessing and controlling the Word Object Model. The first is to use a technique called Object Linking and Embedding (OLE). This allows a program external to Word (written in any programming language, although it will often be Microsoft Visual Basic or Microsoft Visual C++). The other method is more closely tied to Word and requires the software to be written in Visual Basic for Applications (VBA). In our work we have chosen to write use VBA for two reasons. Firstly, our work on Braille production from Word indicated that there are considerable performance advantages over using the OLE approach [1]. Secondly, VBA integrates well with Word and provides a simple mechanism for adding menu items at the same time providing the necessary functionality to produce an appropriate user interface and to control with other software components necessary for the tools (e.g. the modules to do Braille translation and to generate speech).

3 The Preferred Format Tools

As noted above, all of the tools are written in VBA and directly access the Word Object Model. The user selects the tool that he/she wishes to apply by choosing the appropriate menu item, which will appear in the standard Word File menu as shown in Figure 1.

Figure 1: Screenshot of menu items

3.1 Tape Production

A spoken transcript of the document is produced using synthetic speech. The loudspeaker output from computer’s sound card is connected to a standard tape recorder and the text in the document is synthesised and recorded directly onto tape. From the word-processor operator’s perspective, he/she selects the appropriate menu item. He/she is then prompted by the software to press record on a cassette tape player, which is connected to the PC’s sound card. When the document has been spoken, the operator is prompted to press stop on the tape recorder.

The tool will drive any speech synthesiser that meets the SAPI standard. SAPI is Microsoft’s Speech API (Application Programming Interface). SAPI compliant Speech Engines may be obtained from a number of manufacturers and there are freely available speech synthesisers for at least 10 languages (see [4]).

An organisation can configure the synthetic speech through an options screen provided by the tool. The options (see Figure 2) allow the organisation to select which speech engine it wishes to use and also to control the speed and pitch of the speech. It is assumed that once the defaults are set it is unlikely that the word-processor operator will need to change them. However, there are circumstances when this may be desirable. For example, when a letter is being sent it may be desirable to select a voice that matches the gender of the speaker. In addition, in countries where document production in more than one language is common, the operator may need to select the speech synthesiser to match the language options. However, whilst the current system should work in languages other than English, it has not been tested and menu items and option screens are written in English.

The current system is focused exclusively on tape production. However, the system could be adapted to produce speech in other formats. For instance, using an MP3 (MPEG 1, Layer 3) encoder, the text could be distributed by electronic communication (for example email) or on CD for subsequent uploading to an MP3 player (which may be PC-based or standalone). However, there is no real advantage in providing MP3 for subsequent replay on a PC because transferring the document in text form would be more economic and the user could read the document using a screen reader.

Figure 2: Options screen for speech production

3.2 Braille Production

From the word-processor operator’s perspective he/she selects the appropriate menu item. The document is then converted into Braille. If a Braille printer is attached, the Braille copy can be produced immediately. If not, a file in American Computer Braille [2] is produced, which can subsequently be used to drive a Braille printer.

Text to Braille translation is performed by a Braille translation module [1]. A language-specific table drives the Braille translator. The translator will produce contracted or uncontracted Braille. Translation rule tables currently exist for English and Hungarian. Rules can be produced for new languages following the information given in [1].

The Braille production tool attempts to retain the formatting of the original document. For example, highlighted text, (e.g. bold, underlined, italicised) is marked as being italicised in the Braille document. In addition, the ‘header’ of the Braille document gives not only the Braille page number but also the page number of the original printed document from which the text is taken. This is provided so that the reader can resolve references in the text that refer to page numbers in the original document. There are a significant number of such formatting issues, which include the formatting of tables; these are discussed in [3].

The organisation can set a number of default parameters that can be altered by the operator. These include the paper size (in terms of row length and number of rows), whether contracted or uncontracted Braille is used and whether the print page number of the original document is included in the Braille document.

One significant issue with this tool is speed. Whilst the Braille translation is very quick, accessing the Word Object Model and processing the formatting information held there (which has to be done on a character by character basis) can be slow. Moreover, the speed of operation increases significantly with larger documents. For example, a document with 3,648 words is converted in 1:03 minutes and a document three times as long in 6:33 minutes [3]. The figures are derived from running the tool on 233Mhz machine with 128MB memory.

3.3 Large Print Production

The word-processor operator selects the appropriate menu item and a new Word document is produced that has the text in large print. This can be then be printed as a standard Word document.

It may be argued that a large print production tool is not necessary because a user can easily alter print size by selecting all the text in the document and increasing the font size. However, there are some benefits in having a tool for this purpose. Firstly, more sophisticated control over the relative size of fonts can be given. This means that larger text in the original document (for example headings) will be larger than normal text by the same proportion as the original document. The user sets a minimum character size according to the ultimate reader’s preference, this is matched to the smallest character size in the original document and all characters in the large print document are scaled relative to the minimum character size. Secondly, changing the font size can severely disrupt the layout of tables. The tool employs and algorithm that attempts to maintain the original format of tables. Thirdly, altering the font size does not change the size of diagrams and pictures. The tool will enlarge these in the same proportion as the text enlargement. The tool will only enlarge the diagram to the extent that it remains within the print area of the page. In addition to specifying the minimum font size for the large print document. The tool also provides an option to change the font. By default, characters are enlarged but maintain their original fonts. However, the text can optionally be converted to a single font. An example of a simple document before and after enlargement can be seen in appendix 1.

4 Status

The tools, as described above, are currently being evaluated.

The tools have also been adapted to work in another context. By combining the features of the large print production tool and the speech production tool, a switch-controlled talking document magnifier has been developed. This work was motivated by the requirements of a child at RNIB Condover Hall School. The child is a literate switch user, who has some vision. The child needed to be given access to documents in enlarged print (on a computer screen) at the same time as the document was read to him. It was also a requirement that the child had control over the reading process, either sentence-by-sentence or paragraph-by-paragraph.

The modified tool takes a Word document and applies the large print tool to produce an enlarged version that is visible on the computer screen. The tool reads the document using a speech synthesiser. The currently spoken sentence is highlighted whilst it is being read. The tool has options to allow the whole document to be read at once (without user intervention), on a sentence-by-sentence basis (the user activates a switch to move to the next sentence) and a similar paragraph-by-paragraph basis. The result is a simple reading system with enlarged text. One of the virtues of this system it is very easy to use from both the end user’s perspective (single switch control) and for those who produce documents for the system. They simply produce a Word document.

5 Acknowledgements

We would like to acknowledge the support of the UK Guide Dogs for the Blind Association who partially funded this work and the help and advice given by David Thompson. The authors also wish acknowledge the significant contribution made by Nidal Salah to the development of prototype versions of this software and Chris Painter for the motivation to produce the adapted version of the tool.

6 References

1. Blenkhorn. P., "A System for Converting Braille into Print," IEEE Trans Rehab Eng, Vol. 3, No. 2, pp. 215-221, 1995.

2. Sullivan, J. E., “Conversion of print format for Braille” 6^th Int. Workshop on Computer Appli. For the Visually Handicapped, Leuven, pp 1 – 14, 1990

3. Blenkhorn P. and Evans, G. "Automated Braille Production from Word-Processed Documents", IEEE Trans. Neural Systems and Rehab. Eng., Vol. 9, No. 1, (2001), 81-85

4. Microsoft, "Microsoft Agent Downloads", www.microsoft.com/MSAGENT/downloads.htm, current at 27/03/02

Appendix 1 - Documents before and after enlargement. Magnification is set to 300%, font is set to Arial.

Document before enlargement

Document After enlargement