daisy / ebraille

Repository for developing use cases and standard for digital braille
16 stars 5 forks source link

Support for braille style sheets and tactile graphics in untranslated EPUB documents #237

Open jasonjgw opened 1 month ago

jasonjgw commented 1 month ago

Suppose that a user wants to perform all braille translation locally, e.g., to specify a particular combination of braille codes, to specify contracted, partially contracted or uncontracted braille, etc. In this scenario, the use of braille style sheets and support for tactile graphics would still be desirable.

The eBraille format doesn't appear to support such use cases, in that all of the braille is pre-translated and represented in Unicode.

Should there be a standard way to include tactile graphics, braille style sheets, and appropriate braille-related metadata, if applicable, in a generic EPUB document so that the braille translation can be done on the user's device, according to the user's selected translation tables? Are existing specifications (CSS, EPUB, etc.) sufficient for this, or is there more to be said? In the latter case, should it be specified here or in a separate document?

I think the desire to choose braille codes and contraction levels (including mathematics or other codes) creates genuine use cases for this type of support.

bertfrees commented 1 month ago

Since the eBraille format allows for multiple renditions, your use case could be handled by creating an eBraille file set that contains a default rendition with content transcribed using a certain braille code, plus the untranscribed content as a second rendition. This way, your file has all the metadata and characteristics that an eBraille reading system expects.

Of course not all reading systems will offer the functionality that you want, but at least the possibility is there. The downside is that a default braille rendition is required that reading systems can fall back to.

An alternative is to use a single-rendition EPUB, without the braille rendition. This would of course not be a valid eBraille file set anymore, but eBraille reading systems might be developed that can cope with this (or can even handle any EPUB).

As CSS will (hopefully) become more established for braille, and more and more reading systems will take into account CSS, they will just "do what you mean" and you will become less bound to a specific file format.