Inline braille ala SSML?

4 posts / 0 new
Last post

To specify how text is rendered with a TTS-voice we can use SSML:

<span ssml:ph="ˌnɔrθˈist">N.E.</span>

Has anyone considered doing the same for braille? Something like:

<span epub:braille="⠠⠃⠗⠁⠊⠇⠇⠑">Braille</span>

So assuming you mean to handle complexities where automated braille translation might result in the wrong cells being rendered? Interesting idea, but would it be as easy as a single attribute?

Wouldn't injecting the unicode symbols potentially conflict with whether the reader's device is rendering contracted or uncontracted braille? Probably not an issue if only uncontracted braille is used in the attribute, but what if they are reading uncontracted and come across a contraction?

Just as ssml:ph needs an ssml:alphabet to make any sense, it seems like a braille solution would also need more context about what the replacement attribute contains (contracted/uncontracted and possibly whose rules any contractions/formatting used conform to).

And like SSML, there'd need to be a way to pass this information on to the braille device to allow it to make any translations necessary.

Or, in other words, the IDPF is probably not the place to tackle a problem like this, although a solution for web content that could be integrated back into EPUB would certainly be interesting.

Thanks for your thoughts!

The idea would be that the reading device (or printer) wouldn't have to perform any additional processing on the braille. Since the original text would still be there, the reading device could choose to perform its own contractions etc, just like you could choose to use a local TTS voice on a narrated full-text book.

I suppose producing a separate braille-only version of the EPUB (text replaced by braille) would be the way to go today then.

(I havent really thought about this in-depth, it was more of an open question.)

If you really want to embed braille in the publication, a separate rendition would seem the route. But you'll need to wait on the AHL work.

Otherwise, aren't you doubling the content size and complicating production to merge the two?

Secondary menu