[Homeros] ветка украинского языка

[i_chay]

Приветствую всех.

Михаил пишет:
> Нет, всё равно не понял, ну будет и латиница и кириллица, структура
> данных другая, ну и что?

Вы ранее писали, что речевой сервер должен обладать знанием об украинском языке. Я лишь возразил, что не должен, то есть сервер вообще не в курсе, с каким языком работает. Чтобы выбрать синтезатор, серверу не надо знать, на каком языке составлен текст, а достаточно знать какой набор символов принимает тот или иной синтезатор.

>> алфавит можно было бы
>> получать непосредственно от синтезатора 
> 
> Ну они этого не умеют. Точно также, как и нет единого соглашения, как
> получить алфавит от синтезатора.

И после этого вы мои высказывания называете спекулятивными???
Михаил, ну вы же сами прекрасно понимаете, что это не вопрос. Вы же не собираетесь в коде сервера предусматривать различный код для различных синтезаторов (или собираетесь?). Я исхожу из того, что как входной (клиентский) интерфейс сервера, так и выходной (синтезаторный) будут унифицированы. Иными словами, вам все равно придется приводить интерфейсы существующих синтезаторов к определяемому вами же унифицированному интерфейсу сервера.
Те элементы интерфейса, которые не поддерживает исходный синтезатор, вам тем или иным способом (то есть либо средствами конвейеризации, либо через модуль-обертку) придется реализовать самому.
Поскольку интерфейсы вы специфицируете сами (как разработчик сервера), то нет никаких преград в виде "неумения" синтезаторов сообщить о поддерживаемом алфавите или в виде отсутствия международного соглашения относительно интерфейсов вашего сервера.
Это, по-моему,  настолько очевидно, что не предполагает развернутых комментариев.

>>Понятно, что совсем правильно было бы получить от
>> синтезатора идентификатор поддерживаемого алфавита 
> 
> Ну тоже нет на практике ничего такого.

Поймите, Михаил, я не придумал ничего нового; я лишь расширил ваш вариант. Вы и так уже на практике создаете эти таблицы в конфигурационных файлах. Просто вы априори жестко (то есть в исходном коде)  идентифицируете каждую таблицу и жестко ограничиваете их количество. Если вы захотите работать с тремя синтезаторами (русским, английским и арабским), то вам придется переписать сервер. Если же исходить из того, что таблиц может быть более двух, то ничто не мешает вам самостоятельно составить их так же, как вы самостоятельно составили две таблицы для действующего варианта. Впоследствии      вам не придется возвращаться к исходникам, если потребуется добавить третий, четвертый и т.д. синтезаторы.

> >> Во-вторых, сервер (а лучше so-модуль) самостоятельно мог бы строить
>> пересечения для имеющихся множеств и объединять синтезаторы по общим
>> (наибольшим) пересечениям в группы. Соответственно, разности множеств
>> и пересечения составляли бы подгруппы в этих группах. ..
> 
> Анатолий, пожалуйста, приведите примеры, непонятно.

Собственно, действующий вариант представляет собой частный случай общего правила, только часть работы за сервер выплнили вы заранее. У вас есть два множества, называемые вами латиница и кириллица, вы заранее знаете, что их пересечение (при использовании одной и той же системы кодирования) является пустым. Таким образом вы получаете однозначную связь одного множества с одним синтезатором, а другого -- с другим.
Думаю, что логика с третьим (четвертым и т.д.) непересекающимся множеством пояснения не требует.
Теперь допустим, что у нас есть множество, пересекающееся с другим: русский и украинский алфавиты, к примеру.
Вы вычисляете пересечение этих вдух множеств  и таким способом получаете общее для этих алфавитов базовое множество. Затем вычисляете разность между исходными множествами и базовым. Таким образом вы получите два непересекающихся множества: для русского это будет буква ё и  твердый знак, а для украинского -- пять или сколько-то там букв (за точность примера не ручаюсь, но суть он демонстрирует).
Эти два непересекающихся множества вы однозначно связываете с соответствующими синтезаторами.
Эту операцию вы проделываете для всех алфавитов, которые поддерживают синтезаторы, найденные сервером на машине пользователя (в принципе, поскольку алфавиты статичны, то можно заранее провести все вычисления, чтобы сервер не повторял их каждый раз).

>> Активный синтезатор вычислялся бы для ... 
>
> Необходимый атрибут конечного автомата -- множество его состояний. Какой
> его вид Вы предполагали? Множество языков?

По-моему, очевидно, что множество синтезаторов.
Хотя если исходить из модели "один синтезатор -- много голосов", то речь будет идти не о синтезаторах, а о голосах.

> К тому же, если речь идёт о
> детерминированном автомате, то фактически он и работает внутри, 

Я не говорил о том, что внутри не работает ДКА. Я говорил о логике работы его другого варианта.

> Корень проблемы здесь в том, что это всё равно эвристика на удачу,
> Степан явно просил такого не делать. 

Речь идет о выборе синтезатора. Фактически ранее вы написали, что не знаете, как поступить, если таблицы символов для каждого синтезатора в какой-либо своей части являются пересекающимися, и вы императивно исключаете такой случай благодаря пользовательскому контролю содержимого этих таблиц. Я предложил вам механизм, воспринимающий пересекающиеся таблицы как нормальную ситуацию, а не как аварийную.
При желании вы можете всегда ограничить глубину вычисления разностей, то есть, например, не вычислять их вовсе, а сформировать только базовые множества и связать с ними несколько синтезаторов (тогда действительно получится НКА). В этом варианте именно пользователь будет выбирать активный синтезатор (из группы синтезаторов, связанных с конкретным базовым ножеством). Опять показываю на пальцах: если у вас два синтезатора английский и русский, то НКА превращается в ДКА (то есть полностью соответствует действующему варианту). Если у вас три синтезатора английский русский и украинский, то вы получите два базовых множества: одно, связанное с английским синтезатором, и второе, связанное с русским и украинским синтезатором. Очевидно, что выбор второго синтезатора -- это обязанность и право  клиентской стороны (т.е. пользователя).

> нас есть ещё такое
> понятие, как "язык по умолчанию". Анатолий любит слушать цифры всегда
> по-русски, я - языком предшествующего текста. 

Выявление цифрового контекста -- это вообще тривиальная задача даже для действующего варианта: выделите цифры в отдельную таблицу и задайте синтезатор для их чтения в конфигурационном файле (ровно так же можно поступить и для других неалфавитных символов).
Поскольку мой вариант -- это всего лишь расширение вашего, то и в нем цифры выделяются в самостоятельное множество, которому назначается синтезатор по выбору пользователя.

> Суть в том, что
> определение языка, выбор синтезатора, выполнение текстовых
> преобразований должны решаться где-то на одном уровне.

Для такого утверждения нет никаких выдающихся оснований (исключая, разумеется, тот факт, что для сервера уже написан код, в котором, вероятно, это все собрано вместе).
В моем понимании сервер не должен вообще заниматься ничем из вышеперечисленного. Если есть многоязычный синтезатор, то он и займется выявлением языка (если такая информация не поступила от клиента).
Если на сервер возлагается задача выбора синтезатора, то эта задача и должна решаться как задача выбора синтезатора, а не как задача распознавания языка текста.
Обработка текста -- это вообще удел синтезатора. 
Если есть необходимость в помощь разработчикам синтезаторов собрать унифицированный набор функций для обработки текста, парсинга тегов речевой разметки и т.п., то лучше это сделать в виде отдельного API, а не помещать все это внутри сервера.
В противном случае сервер превратится, мягко выражаясь, набор подпорок для "неполноценных" синтезаторов, в которых отсутствует все или почти все, кроме склеивания звуковых фрагментов.

> Ну заведите один язык, который будет ловить 100% символов, назначте ему
> синтезатор и принципиально ничего не изменится. 

Относительно чего не изменится?

> Но будет неудобно для
> пользователя. Так как развёртка цифр и знаков препинания будет в одном
> месте, выбор языка в другом и т. д. Знаки препинаний у нас ещё могут
> быть в трёх режимах.

Вообще-то пользователь не в курсе, где реально выполняется обработка пунктуации.
Все это выносится из сервера в синтезаторы (или в обертки синтезаторов). Если синтезатор не поддерживает режимы чтения пунктуации, то сервер уведомляет об этом клиента и по умолчанию умывает руки.
В результате у вас получается чистый, легкий, устойчивый сервер с расширяемой функциональностью, независящий  от  вариантов реализации конечных синтезаторов. Все необходимые переходники между сервером и существующими синтезаторами (в том числе и опциональный обработчик текста, или пунктуации, или еще чего-нибудь) реализуется отдельно и не входят в код сервера.
Просто речевые серверы Emacspeak --- это не самый лучший образец для построение общесистемного речевого сервера.

    Успехов. Анатолий.