And the problems are rarely one-time occurrences. When the reader figures out what the engine was trying to say they will, in all likelihood, have to make a mental note on how to translate the synthetic gunk each time it is re-encountered to avoid repeatedly going through the same process. If you don’t think that makes reading comprehension a headache, try it sometime.

But this is where the Synthetic Speech Markup Language (SSML) comes in, allowing you to define individual pronunciations at the markup level. EPUB 3 adds the ssml:alphabet and ssml:ph attributes, which allow you to specify the alphabet you’re using and phonemic pronunciation of the containing element’s content, respectively. These attributes work in very much the same way as the PLS entries we just reviewed, as you might already suspect.

For example, we could revise our earlier example as follows to ensure the proper pronunciation for each use of bass:

<p>
    The guitarist was playing a
    <span ssml:alphabet="x-sampa" ssml:ph="beIs">bass</span> that was shaped
    like a <span ssml:alphabet="x-sampa" ssml:ph="b&amp;s">bass</span>.
</p>

The ssml:alphabet attribute on each span element identifies that the pronunciation carried in the ssml:ph attribute is written in X-SAMPA, identically to the PLS alphabet attribute. We don’t need a grapheme to match against, because we’re telling the synthetic speech engine to replace the content of the span element. The engine will now voice the provided pronunciations instead of applying its own rules. In other words, no more ambiguity and no more rendering problem; it really is that simple.

It bears a quick note that the pronunciation in the ssml:ph attribute has to match the prose contained in the element it is attached to. By wrapping span elements around each individual word in this example, I’ve limited the translation of text to phonetic code to just the problematic words I want to fix. If I put the attribute on the parent p element, I’d have to transcode the entire sentence.