Closed murata2makoto closed 8 years ago
It's not technically EPUB technology, so adding a registry seems at odd with the standard. This really should be in W3C if there's a future to it.
Do any reading systems even support the attributes?
A project by the Japanese government uses this attribute.
I do not think that SSML as a whole has a future, but this attribute in EPUB is different.
It needs integration with the web stack if it's realistically ever going to be used to influence TTS rendering. As a formulation for EPUB, no one seems to have the time to invest in inventing support.
It's not even tested in epubtest.org because it's been an across the board fail. Same as PLS. They'd be fantastic for accessibility, but reality has not caught up with theory for these two.
Has the Japanese government created a working implementation of the attributes, or is it just another set of guidelines? We've created guidelines, added them to the O'Reilly books, and still they've gone unloved.
That's why I'm leery of a registry that suggests that support exists for various phonetic alphabets when it's not clear if or when such support will develop.
I am not an expert, but I know that there is an implementation of SSML in Japan. I will ask DAISY people.
Regards, Makoto
2016-09-12 9:41 GMT+09:00 Matt Garrish notifications@github.com:
It needs integration with the web stack if it's realistically ever going to be used to influence TTS rendering. As a formulation for EPUB, no one seems to have the time to invest in inventing support.
It's not even tested in epubtest.org because it's been an across the board fail. Same as PLS. They'd be fantastic for accessibility, but reality has not caught up with theory for these two.
Has the Japanese government created a working implementation of the attributes, or is it just another set of guidelines? We've created guidelines, added them to the O'Reilly books, and still they've gone unloved.
That's why I'm leery of a registry that suggests that support exists for various phonetic alphabets when it's not clear if or when such support will develop.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/IDPF/epub-revision/issues/871#issuecomment-246216000, or mute the thread https://github.com/notifications/unsubscribe-auth/AFPqaNFIGEGpd-00yxR7L6f5GZDiQTtQks5qpJ_XgaJpZM4J58bc .
Praying for the victims of the Japan Tohoku earthquake
Makoto
The Japanese language requires SSML (and PML) very strongly. The reason is that Japan imported CJK ideographic charcters from diffent dynasties of China. As a result, a single CJK ideographic charcter in the Japanese language may have different pronounciations such as To-on, Go-on, and Kan-on. One character is said to have 150 pronounciations.
Sophisticated guessing by T2S engines is sometimes impossible. For example, it is impossible to choose Tomoko and Satoko as the pronunciation of U+667A followed by http://glyphwiki.org/wiki/u5b50. Both are completely reasonable pronunciations.
There is an implementation of SSML and PLS by an on-going project funded by the Japanese government. I cannot say that it is widely used, but I certainly hope its success.
As a value of the ssml:alphabet attribute, x-JEITA-IT-4002 is mentioned in the W3C recommendation of SSML,. It refers to JEITA IT 4002. But, we now have JEITA IT 4006, which is slightly different.
I thus believe that we need a registry for the ssml:alphabet. The registry should enumerate ipa, JEITA IT 4002, and JEITA IT 4006 at least.
My concern is that we don't have precedent for doing this.
We don't own SSML, and that specification mentions a similar registry here: https://www.w3.org/TR/speech-synthesis11/#S3.1.10.1
There was also this draft: https://tools.ietf.org/html/draft-burnett-pronunciation-alphabet-registry-00
Is IDPF really the place to be taking this up?
It appears that neither W3C nor IETF has created such a registry.
I think that a registry is needed, but you might want to revisit this issue after the merge of IDPF and W3C. Then, I can live with a note mentioning two values: x-JEITA-IT-4002 and JEITA-IT-4006.
I found this thread which suggests there was disagreement about how alphabets should be registered: https://lists.w3.org/Archives/Public/www-voice/2010JanMar/0005.html
I can't find anything about why it didn't end up IANA as they were later proposing, though.
I did not know draft-burnett-pronunciation-alphabet-registry-00.
I would like to point out that the mapping from JEITA IT 4006 to IPA is precisely defined. JEITA IT 4006 is nothing but a Japanese-friendly notation of (a subset of) IPA.
Jumping in, SSML is supported in the WIndows 10 TTS engine, by Amazon's IVONA voices (and in the Amazon Echo device) and several other TTS engines. Content containing SSML is passed through the W3C Web Speech Synthesis API on Chrome/Edge/Firefox on Windows to SSML conformant TTS engines. On Mac OS, unfortunately there is no support for SSML by Apple (but a subset of SSML elements is transformable to the Apple speech markup).
SSML does have a future. The ease of using it within HTML via Web Speech API should increase awareness, as will voice-based virtual assistants such as Amazon Echo.
In the educational assessment space, we are looking for implementable solutions for SSML in HTML. Issues are discussed in the following:
https://github.com/mhakkinen/SSML-issues/blob/master/examples.md
Thanks, Mark. But that's SSML markup as defined by SSML, correct? That markup isn't valid in EPUB. EPUB has its own pair of attributes that can be used on any html elments (ssml:alphabet and ssml:ph).
I'm not arguing that SSML doesn't have a future, or that the attributes weren't a good idea, only that they haven't gotten much in the way of support because the implementation and interpretation are unique to epub.
I'm primarily against this specific proposal because IDPF doesn't seem like the right owner of a registry of SSML alphabets.
We really need more information about why this didn't happen as part of the ssml work, and we don't have more time to figure it out, so I'm going to defer this issue off the 3.1 timeline. This is one issue that might benefit being done post merger.
Following note is proposed to close this issue:
Although the [SSML] specification makes reference to a registry of alphabets, one has not been published. As the charter of the W3C Voice Browser Working Group has expired, Authors need to reference Reading System support documentation to determine what alphabet codes are supported. Some common alphabets include: x-JEITA-IT-4002, x-JEITA-IT-4006 and x-sampa.
I am sorry for not making comments here. x-JEITA is also needed when people do not care the difference between x-JEITA-IT-4002 and x-JEITA-IT-4006. x-JEITA is already used.
Is there a way to combine them, like: "Some common alphabets include: x-JEITA (also x-JEITA-IT-4002 and x-JEITA-IT-4006) and x-sampa."?
Your wording looks fine to me.
Regards, Makoto
2016-11-05 22:19 GMT+09:00 Matt Garrish notifications@github.com:
Is there a way to combine them, like: "Some common alphabets include: x-JEITA (also x-JEITA-IT-4002 and x-JEITA-IT-4006) and x-sampa."?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/IDPF/epub-revision/issues/871#issuecomment-258610944, or mute the thread https://github.com/notifications/unsubscribe-auth/AFPqaLJsEV0ONAMH8trQFjZVf_rbzdpkks5q7IJUgaJpZM4J58bc .
Praying for the victims of the Japan Tohoku earthquake
Makoto
Permissible values of the ssml:alphabet attribute are not defined in EPUB Content Documents 3.1. Rather, we rely on the definition of this attribute in Speech Synthesis Markup Language (SSML) Version 1.1, W3C Recommendation 7 September 2010.
However, after this recommendation was published, at least one specification, JEITA IT-4006 (Symbols for Japanese T2S Synthesizer) has been published. Similar specifications may be published.
To allow such specifications for this attribute, I propose to create a registry for this attribute.