The DAISY Consortium commissioned the completion of this survey. The financial
support of the Royal
National Institute of Blind People (RNIB) is greatly appreciated.
In addition to the survey respondents listed in Appendix 5.1, I want to express my appreciation to those who reviewed drafts of this report and provided their comments. Finally, special thanks go to the following individuals who, while they may not have directly participated in the survey, provided me with feedback that has informed my observations and conclusions. These individuals include:
This survey seeks to identify current trends, along with the questions and issues with which producing agencies, software developers, and others interested in generating braille from a DAISY/XML source file have been dealing. While the Overarching Questions for Consideration and Conclusions and Recommendations sections may not offer resolutions, these sections summarize the issues and provide suggestions for next steps.
Highlights include:
This survey of the state of the art of braille production from a DAISY source file was commissioned to assess whether the DAISY XML source file (often known as DTBook) may or may not be meeting the needs of braille producers. In addition, the survey seeks to gauge whether participants have been successful in obtaining electronic source files and what the results of production are when such source files are available. The Braille in DAISY Working Group has, via its email list discussions, identified a number of issues, and this report should be viewed as a supplement to, as well as an expansion of, the issues that have been raised in these discussions.
Some dozen organizations and companies that have expressed interest in Braille in DAISY were contacted in September of 2007 for their feedback. Participants were chosen to reflect a wide range of needs and experiences. Even individuals who were not contacted directly have contributed to the information provided here simply by virtue of their participation in the Braille in DAISY Working Group. I have endeavored to take many of the ideas I have seen discussed on the Working Group's Core and Main lists into account.
This report identifies trends, rather than focusing on an extensive statistical analysis of the responses. Further, while the report does present some agency-specific responses, details are primarily provided for purposes of illustration. Given how rapidly technology is evolving, specific procedures or current practices are likely to be quickly outdated. This report should be viewed as a "snapshot."
The Braille in DAISY Working Group is faced with the need to address the requirements of many stakeholders. Groups impacted by the production of braille from a DAISY source file include producing agencies, professional transcribers, volunteers who prepare electronic files for production, software developers, teachers, parents, and braille readers (especially students who require "perfect" braille to facilitate learning).
With respect to braille production, the word "perfect" is rather subjective, as evidenced in discussions on the Braille in DAISY Working Group email lists. In the context of this report, I endeavor to use the word "perfect" with care. I use "perfect" to describe braille output primarily when respondents used the term during the course of my conversations with them.
What follows are some examples of audiences and their needs. The lists of needs may not be comprehensive; however, they should make clear where needs diverge, as well as where there is common ground.
Although the DAISY Consortium's Structure Guidelines document is not mentioned in each of the lists, below, these guidelines for preparing content are of particular value when creating documents to be brailled. The need for a number of stakeholders to adopt, as often as possible, the most recent edition of the Structure Guidelines cannot be stressed enough. While these guidelines should not be viewed as a "Bible," a concerted effort to follow them ought to lead to consistent DAISY content creation that will benefit all of those interested in improving braille output from a DAISY source file.
Increasingly, being able to produce content that can be adapted to a desired medium is essential. It would be ideal, for example, if a braille software "wizard" were developed that could make modifications to a "master source file," depending on the required mode of presentation. This tool might eliminate what becomes irrelevant when content designed for paper production is presented on a braille display. Also, this tool could shift content around on the fly, such as with tables, endnotes, and footnotes, to provide a braille display user with a tailored reading experience.
Note that while I am not listing the braille-reading needs of those who are not students, their needs are similar to students. The primary difference is that those no longer taking classes may be better equipped to adapt to unusual, nonstandard outputs since they are already literate and can use their reading experience to fill in gaps via contextual clues. A focus on students' literacy, i.e. both braille and subject-specific reading knowledge and skills, is critical to an analysis of how to produce accurate and comprehensible braille in a learning environment.
Mainstream publishers currently do not typically seem to see braille production as a threat to their market. While this remains the case, the time is right to take advantage of the fact that braille production is a value-add that publishers recognize that they are not prepared to address directly. At the same time, some publishers do seem to be beginning to see the sale of text-based electronic content as a possibility in the print-disabled community.
These are general questions raised during my discussions with respondents, as well as questions that have occurred to me, but for which there are no definite answers at this time.
Is DAISY the ideal single source file from which braille can, or should, be created? Does it mirror print enough to give software and humans the information that they need to preserve, or incorporate, the presentational aspects when they are required by braille? Braille transcribers often need both semantic markup, as well as presentational information in the file when they are massaging it before sending it to braille translation software. Can transcribers' needs be balanced and taken into account more fully than they currently are?
Can the DAISY Pipeline provide a platform upon which braille utilities and tools can be built so that there could be a suite of tools with a human-friendly user interface that those with less technical knowledge can use for braille production? Would it be possible to generate a braille source file from the Pipeline that could be sent directly to an embosser? What are the plans for the development of an open source XML-to-braille translator?
Will "Save as DAISY" from Microsoft Word offer solutions to the issues identified by the Braille in DAISY Working Group? This plug-in should be helpful, but it will only be so if all stakeholders' expectations are managed and met. For example, if transcribers or producing agencies will benefit from a template of styles, who will develop, maintain, and distribute these style templates? If braille translation software developers should take "Save as DAISY" into account, then they need to know what to expect, in terms of consistent output, as well as when they can anticipate having examples to support modifications to current software or new tool development.
What are the prospects for adoption of the Portable Embosser Format (PEF) worldwide by both producing agencies and embosser developers? If the PEF is not the answer, what solution can meet the needs of those wanting to share braille files?
When should braille files be shared, as part of the Global Library, and when would it be advisable to share another kind of file as the source file from which a range of alternate media are generated?
Generally, all respondents want to be able to produce better braille from DAISY, or other electronic source files, than they can produce today. Respondents' expectations for what better, or even perfect, braille would mean, ranged along a spectrum, depending upon the kind of content produced and the human resources available to provide intervention for preprocessing a source file.
Saving time and decreasing costs were often mentioned as desirable. In addition, the ability to generate well-marked up content, as a predictable and consistent foundation from which braille output could be generated would be ideal. This foundational markup, whether or not DAISY serves as that foundation, should be transformable based on local braille rules.
Most agreed that producing well-formatted novels with little human intervention should be possible, even if it is not yet quite so today. But several respondents felt that producing content such as math, science, music, graphics, texts with notes and/or tables, and non-English language textbooks would likely always require at least some human experience and interpretation.
For purposes of this discussion, the XML available may or may not be DTBook. Sometimes agencies receive, or create, XML that they then transform to DAISY as the output format.
Survey participants were selected with an eye toward choosing organizations along a spectrum of content production experience. Several organizations that are producing content from XML have found that DAISY is not sufficient, at least in some cases, so they have developed specific project-related DTDs or are using another format, such as the Book Exchange Format (BXF) which is then transformed to DAISY. Some of the organizations that have adopted a variety of work-arounds include RNIB, Vision Australia, and Deutsche Zentralbücherei für Blinde, German Central Library for the Blind (DZB). These agencies, along with other respondents who commented on this question, are committed to DAISY, but they simply find it necessary to adopt a range of approaches in order to efficiently produce braille content.
In short, several respondents stated, or implied, that the idea of DAISY as the "single source file" is a great one, in theory, but in practice, DAISY, as it exists today, does not always meet their needs.
When producing agencies receive XML, they often find that the markup is not consistent and requires considerable editing by hand. Also, updating of content proves difficult such as when a new edition of a book is released. Once a consistent style has been identified, however, repeat jobs become faster and easier. Periodicals especially lend themselves to rapid production.
Software developers identified several items that they have encountered when they have worked with electronic files. These include:
The following list should be viewed as a snapshot of ideas mentioned at the time survey interviews were conducted in September of 2007. These projects may be subject to change based on a range of factors such as the availability of human and financial resources, changes in agency priorities and best practices, etc. Activities and projects mentioned include:
Several survey participants indicated that they are working with electronic source files to one degree or another. Word and PDF are the most prevalent, but Quark, FrameMaker, and TEI were also mentioned.
Highlights of the survey responses include:
Note that since the survey interviews were conducted, the DAISY Consortium has announced its collaboration with Microsoft and Sonata to develop a "Save as DAISY" plug-in for Word. Once this plug-in becomes available during the first few months of 2008, production of braille may be streamlined, especially if missing features in the current conversion options from Word to DAISY are identified. As soon as braille translation software developers can see even a prototype, they should be able to provide feedback and take this plug-in into account as they make plans to support end-users with appropriate styles and templates. In addition, the "Save as DAISY" capabilities should be considered in the development of training materials for transcribers, perhaps even via online demonstrations or seminars.
Most participants indicated that they were already providing as much support as they were able to via staff time to monitor and contribute to either or both Braille in DAISY Working Group lists, participation in the survey, attendance on conference calls when possible, etc. It seems that the group has the potential to become more fully engaged once they understand the path of the project and are tapped to complete small, clearly-defined tasks that dovetail with their knowledge and in-house projects.
Specifically, Vision Australia offered to be available as a test environment. gh is willing to be called upon and will contribute as time and resources permit, especially when the Consortium's work aligns with their efforts, such as work on math and science. The National Association for the Blind may have some human resources available, especially in relation to language localization. RNIB can offer some software engineering assistance. RNZFB is especially interested in producing braille from TEI, and it is conceivable that work in that area could be leveraged into a Pipeline conversion module. SBS hopes to contribute software engineering resources, but a timeline for availability is unknown at the moment.
Generally, then, some human resources are available, but these additional resources must be harnessed strategically. At the same time, the time and knowledge that are already available must continue to be employed to best advantage.
While many survey participants are using Duxbury, a large number are not. The percentage of Duxbury users may be biased given that this survey reached a significant sample of English-speakers.
Producing agencies in Sweden, Norway, the Netherlands, and Germany are using independently-developed software. RNIB uses Megadots and believes that support for this DOS-based product may be discontinued relatively soon. Most, if not all, of these organizations would prefer not to rely on software that has a limited "shelf life" and/or requires them to be intimately involved in maintaining it.
Those who currently use Duxbury's Braille Translator generally feel that, in order to produce braille from DAISY, they must do a considerable amount of preprocessing. Some wish that Duxbury made better use of the DAISY markup it receives, while a few others feel that Duxbury's software is fine, in terms of its output, but better tools should be made available to support preprocessing. In short, some believe that Duxbury is fine, but they would like to speed their human productivity with it.
Note that since these interviews were conducted in September, Duxbury's software development has continued. A preprocessor to support the analysis of a DAISY/NIMAS source file is expected to become available.
One suggestion is to create a module, perhaps in the Pipeline, that would generate a file for import into Duxbury for those who want it. The news regarding a forthcoming Duxbury preprocessor may meet this need.
Gh is particularly interested in the status of Duxbury's support for processing graphics. Like others, gh would like to have its skilled employees focus on complex braille issues, rather than those employees having to complete more mundane tasks, such as cleaning up a file from within Duxbury. There are routine tasks that utilities that could interface with Duxbury should be able to address, with minimal human intervention.
Those who use Duxbury have some difficulty understanding why PEF might be needed, but it is virtually essential for those who do not use Duxbury. Many survey participants advocated the need to improve braille production from DAISY, first, but perhaps it is possible for these two activities to progress in parallel with one another.
Those who support PEF cite the following positive outcomes that could result from implementing the PEF.
PEF could:
Questions and concerns raised regarding the implementation of the PEF include:
Respondents were unanimous in their desire for batch processing of electronic files to braille, although suggestions regarding how to achieve this goal varied. No one seemed to feel that the DAISY source file, itself, needed modifications to support batch processing.
Some people wanted batch processing to tie to Duxbury, while others did not believe that this approach is the best one. Those who wanted batch processing, independent of Duxbury, either did not use Duxbury or were uncomfortable with the somewhat proprietary nature of a Duxbury file as the output.
Those who do use Duxbury suggested, perhaps, that an open API could be developed for the software so that an external program could call Duxbury. A further idea is to have the option to drop a batch of files into a server environment and have Duxbury process them. One participant also suggested that users should be able to override the default settings in Duxbury for processing a batch.
The groups involved in generating braille from a DAISY source file all have the same ultimate objective, but each brings extremely diverse knowledge and approaches to the table when trying to meet the objective of better, if not perfect, braille.
The knowledge-base required to achieve consensus is extraordinarily limited due to the range of braille output formats worldwide and the need to know XML, generally, or DTBook (DAISY XML) at a minimum. The group needs more skilled human resources in order to focus on this effort. Those who work on this project need to be prepared to think innovatively. In short, only a few people are able to bridge the gap between braille and XML, and those people need to have an incentive to step forward. Perhaps the Consortium can find the resources to train a braille expert (in XML) who would be available to serve as a knowledge-bridge.
Software tool developers must be convinced of the urgency of assuring that their tools can work with DAISY content. Would the DAISY Consortium consider collaborating with an organization, such as the World Blind Union, to collect statistical evidence to demonstrate that there is a legitimate DAISY production market? Perhaps there is a "chicken and egg" situation in which some organizations have been waiting for tools to produce braille from DAISY, and the tool developers have been waiting for DAISY content, in order to understand how braille should be produced from it. In the meantime, several organizations have resorted to working around DAISY in order to produce braille. Clearly, continuing this situation is neither beneficial or efficient.
Will the DAISY community join together to build an XML-to-braille translator in order to prevent individual Members from having to re-invent braille production tools?
More sample content must be collected, and/or software tool developers need to be informed about the content that currently exists. The content collected for the DAISY OK Project is expected to prove useful to many of the stakeholders interested in producing braille from DAISY.
Continue to expand DTBook, as necessary, to include semantic elements that would be helpful in braille production. Additional elements should eliminate the need for organizational-specific DTDs.
Consider braille as the Microsoft Word "Save as DAISY" plug-in is developed, and solicit assistance in working with software developers and transcribers to take advantage of the transformation capabilities from Word that should become available. In this effort, pay particular attention to the need both to capture semantic information, as well as presentation information when the "look" of a document is relevant to braille output. Explore whether there may be resources available to support online training to effectively use this plug-in in a typical braille production environment.
Include a "Best Practices" section in the Structure Guidelines for the use of a consistent set of styles to be employed when creating DTBook files. An example might be as simple as differentiating a block paragraph from an indented paragraph.
Consider holding a face-to-face meeting during which producing agencies, especially those with XML experience, along with transcription experts, and translation tool developers, would work through one of the braille rule sets together. The outcome of such a meeting should identify whether there are gaps in DAISY and encourage software tool developers to better handle what DAISY does currently offer.
In lieu of a face-to-face meeting, the Braille in DAISY Working Group should seriously consider implementing a collaborative writing platform, such as a wiki, and rely less on email list discussions. A collaborative writing environment should permit a consistent and thorough assessment of a braille-rule set, and it should permit long-term capturing and archiving of decisions.
It is essential that software tool developers become involved in the discussion. The involvement of software developers will permit another perspective regarding changes to the Standard so that such proposed changes may be taken into account as early as possible.
Whether the next step is implementing a collaborative writing environment, holding a face-to-face meeting, or both, DAISY Consortium Members and Friends who are committed to monitoring the Braille in DAISY effort, at a minimum, or concretely contributing to it, need to see the group taking at least small steps toward our common goal. Email discussions often seem to result in people "talking" past each other, or over one another's heads. Perhaps a focus on the braille rules, rather than DTBook (which may be less known to those who are not technical), might yield results that will move us forward more quickly.
The following list of survey questions was emailed to all participants in advance of a phone or Skype call. One respondent chose to provide his answers via email.
Questions for Consideration1. What do you see as the key outcomes for the DAISY and braille project?
2. What general problems are you seeing when you have been trying to process (text with) well-marked-up XML?
2.1. Especially with respect to software, how can we help you help your customers to produce better output?
3. Can you outline any development projects you are undertaking or involved in that might influence or contribute to this project?
4. To what extent do you use electronic files in braille production? Please focus on XML and DAISY specifically, although we are interested in gauging what kinds of electronic content you are receiving and what your source(s) for that content are.
4.1. How do you think the availability of electronic source files will change for your organizations over the short/medium/long-term?
5. To what extent can you contribute resources to the DAISY and braille effort?
6. Are you happy with the braille translation software you are using? What changes would you like to see?
7. Do you think the Portable Embosser Format (PEF) could be relevant to your organization? For details, see: http://www.daisy.org/projects/braille/braille_workarea/pef.shtml.
8. For software developers only, we understand that producers/transcribers wish to process output in batches. Is there anything that might be needed in DTBook that would facilitate this batch production, or will software be adequate, with respect to its user interface, to guide producers as to how to achieve this goal?
Posted January 15, 2008.
Status: Final Report - all comments incorporated as received
Author: Jennifer Sutton