[Homeros] I: Все выводы по вопросу разметки и смены синтезаторов

[Michael Pozhidaev]

Всем доброго дня!

Собравшись с мыслями и крепко всё обдумав, хочу привести  такое решение:

начинка vm-1.5 будет уметь менять синтезаторы внутри соединения, но эта
возможность будет доступна пока только для использования с его
собственным клиентом voiceman. Другими словами, экранные чтецы всегда
пока разговаривают одним и тем же голосом. 

Если кому-нибудь покажется, что мы решаем "выдуманную
проблему" по части общения с чтецами, то предлагаю написать мысли по
следующим пунктам. Пока никто не покажет, что на самом деле всё хорошо,
будем считать, что проблема всё же есть.

Исходные данные:

1. голосом называем некоторый параметр речи, который не выражается
изменением таких атрибутов как скорость, высота и громкость. В
терминологии vm это можно решить только путём добавления в конфиг нового output'а.

2. внутри emacspeak и orca есть механизмы, которые могли бы быть
использованы для выделения различных элементов разными голосами.

Что требуется решить:

1.  нужно ли пользователям сейчас и в будущем вообще возможность
выделения разных элементов разными голосами. Например, читать
гиперссылки женским голосом. Можно ссылаться на работу других чтецов,
показывая, что без этой фичи озвучка Linux сильно отстаёт. Если видно,
что это никому не нужно, OK, проблема действительно выдумана и вопрос
закрывается;

2. рассмотреть связку чтец->речевой процессор в теории. Рассуждая
абстрактно, можно выделить два подхода, данные отдаются на прочтении с
семантической разметкой и не семантической. Семантическая разметка
подразумевает, что сервер получает не конкретно команду сменить голос в
нужном месте, а информацию о назначении блока. То есть, сам решает,
хочет он сменить голос или нет. В не семантическом подходе сервер просто
подчиняется требованию чтеца сменить голос. Из этих двух подходов нужно
выбрать нужный. Плюс семантического подхода очевиден, единое поведение
для всех чтецов;

3. реализация семантического подхода: как именно разметить входные
данные? Могут ли экранные чтецы отдать такую разметку? Если они такое
отдать по определению не могут, то всё, эту возможность
отметаем. Более-менее понятная форма мне известна в виде Aural CSS, но
тут, видимо, есть со мной не согласные;

4. реализация не семантического подхода: требуется ввести имена
голосов. Можно называть их как угодно, но обычно используют человеческие
имена. Можно сослаться на протокол speech-dispatcher, в котором есть
такая команда. Описать, как в этой команде выбираются имена. Как этой
командой пользуется orca, если пользуется. Что происходит при работе
emacspeak с speech-dispatcher. Желающие могут попытаться обосновать, что
этот протокол имеет сильные плюсы и может рассматриваться как стандарт,
но что-то мне подсказывает, что в нём полно ненужного, и нет нужного. Из
серии нужного:  необходимо помнить, что мы меняем голос сугубо только
для одного языка. То есть команда смены голоса должна явно говорить,
для какого языка меняем голос. Коли в России принято переключать
синтезаторы внутри сервера, протокол должен учитывать такую
особенность. Ни в коем случае не клиент;

5. главная проблема не семантического подхода: имена голосов должны быть
общеприняты. Если чтецы будут отдавать эти команды по принципу "имя John мне
нравится больше, чем Joe", то нас ждёт кавардак. Допускается ввести
отображение имён голосов какой-нибудь таблицей для каждого чтеца.

6. решить, вообще есть ли что-нибудь такое в протоколе emacspeak. Думаю,
что должно быть, но сильно специфично для некоторого из возможных аппаратных
синтезаторов. Допускается, что выбираем протокол этого синтезатора и
всегда просим emacspeak говорить на нём;

7. показать, что решения по предыдущим пунктам долгоиграющие, и всё
завтра не сломается;

8. показать, что это реально реализовать, то есть предложение сделать
новый протокол и пропатчить orca и emacspeak, очевидно, не годиться.

Если у кого-то в голове есть ясная схема, показывающая, что по всем
приведённым пунктам на самом деле всё хорошо, да, готов признать, что
проблемы нет и это должно быть. В противном случае предлагаю считать,
что это пока невозможно, даже если в теории у всех всё хорошо. Лучше
ссылаться на стандарты, но допускается оперировать и понятиями
де-факто. За сим всё, можно думать неограниченное время, т. к. текущая
работа уже не зависит от принимаемого решения. Это на будущее. Хорошо,
если на wiki, но можно и сюда, сам потом поправлю и выложу.

-- 
Michael Pozhidaev. Tomsk, Russia. E-mail: msp на altlinux.ru
Info: http://www.marigostra.ru/