Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jasonjgw opened this issue Aug 1, 2024 · 1 comment

Comments

@jasonjgw
Copy link

jasonjgw commented Aug 1, 2024

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants