First eBraille Public Working Draft is Published
Over two years in the making, the first eBraille public working draft has been published. This is an exciting development in the future of digital braille as we ask for feedback, especially from organizations that have not yet been directly involved in the working group that created it.
What’s in the Draft?
The draft deals with the technical details of the spec. It is primarily meant for organizations that develop software that will read or write eBraille files. While the technical details of the document will likely require a deeper knowledge of publishing technologies to follow, there are many informative sections that provide you with a higher-level overview of the inner workings of the format.
None of the technical information is necessary to create braille. For example, you don’t need to know that the eBraille file contains a package document called package.opf to make an eBraille file. You don’t even need to know what a package document is! If you’re curious, it’s a file that contains all the metadata, the manifest, and the spine of the file. What’s metadata, a manifest, and a spine you ask? It’s all information that tells software what is inside of the package to aid navigation and file organization.
Why don’t you need to know the deeper technical details? Because it will be handled by the software that creates eBraille files. Those options will start with the BRF to eBraille converter that APH is developing and will be released as a free, open-source project next year. You’ll need to provide some information, like the metadata, but you’ll do that via a user interface that presents you with fields like “Title:”, “Author:”, and so on; or is pulled automatically from your document by the software. If you’ve ever created a braille title page, then you will already be familiar with some of the information that is needed for metadata.
What’s Next?
This first draft is just that, a draft. We need feedback, especially from organizations that develop braille transcription software or software that will support reading eBraille files.
Feedback will be incorporated into incremental versions of the public working draft. Once we get it into a state that can serve the needs of our community, then we can publish the complete specification, which should happen toward the end of the year.
What Else?
Guides are coming later. These guides will be more interesting to folks with braille experience, including braille users, transcribers, teachers, and members of standards organizations. Many of those folks are already represented in the working group but we know there are plenty of people out there that could still offer feedback.
There are two guides. One is for tagging the document and tagging is used to represent the structure of the document, ie. the headings, paragraphs, tables, etc.
The other is the styling document which tells reading software how to present the tagged items to the reader — whether an item gets a blank line, indentation, and other kinds of braille formatting. Both include technical information, too, but anyone with braille experience can review them and offer feedback about what is missing or could be changed.
The Journey Continues
We’re not done. We still need to publish the guide documents and we will continue to refine the spec and guides based on feedback from the field and discussions within the working group. We hope you will be involved and please give a big thank you to the many, many people that contributed to the creation of this first public working draft. Their names can be found in the acknowledgements section of the draft. Let’s all continue to work together to guide the future of dynamic braille!