Skip to content

Technical Analysis

Jump to bottom
Avneesh Singh edited this page Oct 23, 2022 · 4 revisions

Introduction

This document derives the technical requirements from the use cases submitted to the ebraille repository and analyzes which existing standards can meet the technical requirements. The objective of this analysis is to provide recommendations for deciding the direction of the project from here on.

Analysis

The following sections explains which standards support the technical requirements and which are not able to support the requirements. It is worth emphasizing that Inability of a standard to meet a requirement at its current state does not mean that the standard cannot be extended to meet the requirement.

Note: Braille formats like BRF, BRA, BRL etc. are represented by the term text based braille formats.

1. Requirements for a standalone content document

We identified the following standards as candidates:

  • Portable Embosser Format (PEF)
  • Text based braille formats (BRF, BRA, BRL etc.)
  • DAISY XML (DTBook.xml)
  • XHTML/HTML (At this time we are considering XHTML and HTML as a single entity, the choice between the two would be made in later stages)
  • Linear braille
  • Markdown

PEF and text based braille formats are specialized braille formats widely used across the world. There is well established infrastructure of tools for them.

DAISY XML and XHTML/HTML are widely used in the world of digital publishing and HTML is the most widely used mark-up language for the web. There is well established infrastructure of tools for them.

Linear braille is one of the braille specific standard which could not achieve the required level of adoption and infrastructure of tools is not widely available.

Markdown is very limited as compared to DAISY XML and XHTML/HTML. DAISY XML and XHTML/HTML are publishing formats while markdown is writing format which is designed to make it easy to format simple text documents.

Therefore, we considered PEF, text based braille formats, DAISY XML and XHTML/HTML for our analysis.

Requirements

1.1. Reflowable text: Existing braille formats like PEF and text based braille formats do not address this requirement. HTML and DAISY XML (DTBook.xml) support it.

1.2. Braille text and graphics in the same content document: Existing braille formats like PEF and text based braille formats do not address this requirement. HTML and DAISY XML (DTBook.xml) support graphics and text in the same document.

1.3. Enable navigation to structural elements within the document (move to next heading, next paragraph etc.): Existing braille formats like PEF and text based braille formats do not address this requirement, though PEF can be extended to have links. HTML and DAISY XML (DTBook.xml) support it.

1.4. Enable special operations like showing/hiding some text, emphasizing or suppressing some text etc.: Existing braille formats like PEF and text based braille formats do not address this requirement. HTML and DAISY XML (DTBook.xml) provide mark-up, which can help to achieve it to an extent.

1.5. Enable the use of alt-text and extended descriptions: Existing braille formats like PEF and text based braille formats do not address this requirement. HTML and DAISY XML (DTBook.xml) support it.

1.6. Make available electronic reading material in transcribed braille characters instead of displaying the text characters converted on the fly into braille characters: Supported by existing braille formats like PEF, text based braille formats etc. Also Supported by HTML, DAISY XML (DTBook.xml).

1.7. Enable braille reading system to switch to another code: Existing braille formats like PEF and text based braille formats do not address this requirement. EPUB 3.0 and 3.0.1 (earlier versions) supported switching.

1.8. Enable dynamic arrangement of the spatial material instead of using a fixed layout: Existing braille formats like PEF and text based braille formats do not address this requirement. For HTML and EPUB, we should explore if this can be done through CSS or by extending CSS.

1.9. Establish common worldwide standard for encoding of braille characters: The working group has been discussing encodings like Unicode ASCII, Nemeth etc. To ensure interoperability and worldwide adoption, it is important to achieve an agreement on standards for braille encoding. It is more of a political challenge to achieve consensus. We will need the backing of braille authorities to achieve it. We would prefer that both 6 and 8 dots braille is supported, and Unicode looks a viable option for it, however the final decision is not made at this point of time. PEF, DAISY XML (DTBook.xml) and XHTML/HTML support Unicode.

Related use cases

2. Requirements for set of content documents weaved into a publication

2.1. Enable logical reading order of the content documents: PEF is a single XML file, therefore logical reading order comes with it. Text based braille formats do not have the concept of binding multiple files in logical reading order. DAISY, EPUB and Web Publications provide this functionality.

2.2. Enable navigation across the structural elements of multiple content documents (go to a section, a page etc.): Text based braille formats do not address it. DAISY and EPUB support it. PEF is a single XML file, which can be extended to use links for internal navigation.

Related use cases

3. Metadata

3.1. Publication metadata for the users/readers: Doublin core metadata addresses this requirement to a very good extent.

3.2. Accessibility metadata for the users/readers: Accessibility metadata in schema.org and ONIX addresses this requirement to a good extent.

3.3. Braille metadata for the users/readers: We would need to add the missing pieces and build consensus on it.

3.4. Braille metadata for reading systems: We would need to add the missing pieces and build consensus on it.

Related use cases

4. Identify or develop specifications for displaying graphics

There are many formats for showing images and graphics for example PNG, JPG, SVG etc., we need to figure out if the requirements of multiple line braille displays can be fulfilled by some of the existing formats or if we need to start work on a new format for displaying graphics through braille dots. Therefore, this topic needs in-depth research in close collaboration with the developers of reading devices and reading systems.

Related use cases

5. Packaging

Enable packaging of multiple files of braille publication. This should be an additional specification to ensure that unpackaged ebraille and packaged ebraille are both valid. The packaging requirement can be addressed by using EPUB 3 container, Light Weight packaging format, zip etc.

Related use case

6. Additional design considerations

6.1. Support multiple versions of the same content inside the publication. For example, one set of files can be of contracted braille and another version of the same content in uncontracted braille, or one set of files can be in braille and other version of files of the same content in print text: The earlier versions of EPUB 3 supported it, but it was removed from EPUB 3.3 due to lack of adoption in the publishing industry.

6.2. Ability to switch from one version to another version of the content file without losing the reading position. 6.3. Ability to read reflowable braille as well as emboss the braille from the same braille publication. It is worth mentioning that in the principles which we established for this project, we prioritized supporting reflowable braille in case we end up with competing priorities.

Related use cases

Conclusion and recommendations

Please visit Conclusion and Recommendation page

Clone this wiki locally