При построении набора паттернов использованы 1 550 900 словоформ из словаря batov's dictionary™. Результаты работы консольной версии BaH и TeX-версии – 5 009 222 переноса – совпали полностью.

Набор ruhyphib.tex содержит 18543 паттерна. Размер набора – 121913 байт – превосходит размеры канонических наборов паттернов в среднем в три-четыре раза, за счет паттернов, обеспечивающих корректные переносы в редких словах, узкоспециальных терминах и сложных случаях.

Скорость работы версии, использующей паттерны TeX, превышает скорость работы классической версии в среднем в пять раз: 6 секунд против 30 (на словаре в 1,6 млн слов). Это нормально: по скорости соперничать с TeX невозможно. Удивляет другое: превосходство оказалось гораздо меньше, чем можно было ожидать. Для своего класса алгоритмов каноническая версия (в ее основе – регулярные выражения) работает очень быстро. Отмеченная разница – разница в скорости работы ядер. Скорость расстановки переносов в приложениях определяется совсем иными факторами; например, в InDesign расстановка переносов в словаре, с которым консольная версия BaH справляется за 30 секунд, требует нескольких часов.

Речь идет об атрибуте "Предпочтительность".

В процессе работы алгоритм использует переносы пяти уровней предпочтения, но во внешний мир передает два значения: "наилучший/допустимый" и "нежелательный". Как показали эксперименты, этого вполне достаточно; более тонкая градация компоновщиком InDesign в реальных проектах проявлена быть не может. Если в будущем понадобится – реализуется легко.

В настоящее время к атрибуту "Предпочтительность" следует относиться сдержанно: шлифование этой грани алгоритма только-только начинается. Работа предстоит сложная и кропотливая. Надеяться на быстрый результат не приходится. Но проделать этот путь необходимо; в противном случае будем иметь бессмысленные варианты, в духе Winsoft.

Работа над ядром 4-го поколения шла параллельно с работой над ядром версии 3.01. Соответственно, качество переносов новой версии столь же высоко, как и у ядра 3.01. Однако издания, подготовленные с 4-ой версией, должны выглядеть не в пример лучше: в новой версии плагинов поддерживается способность компоновщика InDesign® работать с переносами разной степени предпо­чти­тель­ности. Это собственно то, из-за чего я в свое время и обратился к InDesign®.

Версия 4.00 поддерживает переносы лучшие, регулярные и допустимые. Соответственно: одна, две и три тильды:

авиа~дви~~га~~те~~~ли
бро~~~не~тан~~ко~вый
бы~~стро~кры~~лый
внеш~~~не~эко~~но~~ми~~че~ский
внеш~~~не~по~~ли~~ти~~че~ский
впол~~~не
древ~~ней
древ~~~не~рус~ский
жиз~~~не~дея~~тель~ность
крае~уголь~ный
мень~~~ше
мет~ок~~си~ими~~но~аце~~та~~та~~~ми
ме~~тео~про~гноз
ми~~кро~скоп
ра~~бо~~~та

Поддержка переносов разной степени предпочтительности была заложена в алгоритм еще в 1996 г. Но, поскольку до 2007 г. BaH™ работал с Corel Ventura™, задействована данная возможность не была.

Из штатных инструментов InDesign® переносы разной степени предпочтительности поддерживает WinSoft. Однако реализовано это не всегда внятно:

а~~~ви~~ад~~ви~~га~~те~~ли
бро~~не~~тан~~ко~~вый
во~ен~~ком (правильно: во~~ен~ком)
воз~ду~~хо~~ле~~че~~ни~~~е (правильно: воз~~ду~~хо~ле~~че~~ни~~~е;
      лучше: воз~~ду~~~хо~ле~~~че~~ни~~~е)
воз~ить~~ся (правильно: во~~зить~~~ся)
во~й~~~на (правильно: вой~~~на)
...

Несмотря на почти полную готовность модуля для CS6 работы еще предстоит много.

Главное отличие Профессиональной редакции от Стандартной и Расширенной – в поддержке пользова­тель­ских правил на уровне ядра.

Профессиональная редакция будет поставляться с набором пользовательских правил, отражающим со­вре­менные тенденции в расстановке переносов.

Формат файла с пользовательскими правилами Профессиональной редакции несущественно отличается от формата файла Расширенной редакции; поддерживаются кодировки 1251 и UTF-8 (без BOM) на плат­фор­мах Windows и Macintosh.

Решить задачу удалось лишь после того, как был решен вопрос о выборе кодов, используемых для знаков ударения. Обобщив пожелания пользователей BAH, я остановился на символах Greek Tonos (Unicode – 0384), Prime (Unicode – 2032), Combining Accute Accent (Unicode – 0301). Выбранные символы присутствуют в Times New Roman, Arial, Verdana, Tahoma и др. шрифтах, входящих в поставку Windows. С учетом особенностей Adobe InDesign советую ставить знак ударения перед соответствующей гласной. Далее символ можно позиционировть, используя стандартные средства InDesign. Слова "С учетом особенностей Adobe InDesign" написаны не случайно. Конечно же, мне известно, что Unicode 0301, Combining Acute Accent, имеет "отрицательный кернинг", и, если его поставить после гласной, он автоматически встает над ней. Использовать такую возможность – первое, что приходит в голову. С этого я и начал. Во всех случаях результат идеальный... за исключением слов типа "собака", когда перенос происходит непосредственно после ударной гласной. Оказалось, что форматирование знака ударения (какой бы код для него ни использовался) распространяется и на дефис – знак переноса: например, если опустить знак ударения на один пункт, дефис тоже опускается на один пункт. Если поднять – то и дефис поднимается... Преодолеть это не удается никакими ухищрениями. Зато постановка ударения перед гласной позволяет в принципе уйти от этой проблемы...

Новая система тестирования была опробована на модуле Hunspell. Протокол тестирования будет опубли­ко­ван после выхода релиза Adobe® InDesign® CS7.

Первое впечатление – модуль работает гораздо лучше по сравнению с предыдущими версиями. И – опять же, это первое впечатление, которое еще предстоит проверить, – превосходит по качеству модуль Winsoft. Более точно смогу сказать через несколько дней.

Протоколы тестирования модулей от Winsoft для CS5.5 и CS6 совпадают побайтно. А поработать было над чем (см. запись от 04.05.2010).

антропом~~етр
ави~~абилет
ави~~абомба
...
австро-и~~тальянский
автос~~цепка
архейско-протерозо~~йский
...
без~~ъядерный
без~~ъязыкий
без~~ъязычен
без~~ъязычна
без~~ъязычно
без~~ъязычны
без~~ъязычный
без~~ыдеен
без~~ыдейна
без~~ыдейнее
без~~ыдейно
без~~ыдейности
без~~ыдейность
без~~ыдейны
без~~ыдейный
без~~ызвестный
без~~ыменный
бере~~йтор
...
бо~~йскаут
бро~~йлер
...
валяльно-во~~йлочный
валяльно-об~~увной
...
во~~йдет
во~~йдете
во~~йдешь
во~~йдите
во~~йду
во~~йдут
во~~йдя
во~~йлок
во~~йлоке
во~~йлочно-валяльный
во~~йлочно-ветвистый
во~~йлочный
во~~йн
во~~йна
во~~йнах
во~~йне
во~~йной
...
и далее в таком же духе. Полная версия протокола тестирования помещена в архив.

Adobe® же в состав InDesign® CS5.5 включила именно паттерны TeX. Следствием этого явилось общее большое количество ошибок (см. записи от 15.05.2011, 08.05.2011), среди которых можно выделить не­кор­ректный перенос слов, пишущихся через дефис, и слов, в состав которых входит буква "ё". Всё это пре­одолимо. Затратив два выходных дня (сюда, конечно, входит не только доработка набора паттернов, но и многократное тестирование на словарях пяти видов), удалось привести работу алгоритма в соответствие с тем, что предполагал получить разработчик набор паттернов (Copyright 1999-2003 Alexander I. Lebedev). Я не стал исправлять ошибки оригинального набора паттернов, поскольку свою задачу видел в том, чтобы сделать доступными в InDesign® неискаженные авторские варианты.

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

Под неверной реализацией я понимаю следующее: Hunspell (Adobe® InDesign® CS5.5) и OpenOffice.org Writer ставят переносы не там, где это должно быть в соответствии с используемым набором пат­тернов. Или наоборот – не ставят там, где положено. Вот несколько примеров:

Должно быть (набор паттернов hyph_ru_RU.dic)	Hunspell (набор паттернов hyph_ru_RU.dic)
ав-то-опе-ра-ци-он-ной	ав-тоо-п-е-ра-ци-он-ной
бес-связ-ный	бессвязный
взбал-ты-ва-ние	вз-бал-ты-ва-ние
воз-ду-хо-увлаж-ни-те-лей	воз-ду-хоу-влаж-ни-телей
един-ствен-ный	единствен-ный

Далее в таком же духе: около 40 тысяч случае насчитал.

Протокол испытаний в Архив помещать не буду. Надеюсь, ошибки в коде устранят быстро. Написал Раилю Алиеву. Подождем...

...и ждать выхода триальных версий. Конечно, определенные предположения относительно того, что это за модуль, были. Поэтому, когда Максим Белецкий получил доступ к CS5.5, я его попросил проверить, как перенесет фамилию "Стржельчик" модуль от Hunspell. Вариант "Стр~~жель~~чик" сомнений не оставлял: использованы паттерны TeX. Но чтобы определить, какой же именно набор паттернов использован, сле­до­вало дождаться выхода триалов. 5 мая триалы стали доступны для скачивания. Дальше все просто: набор паттернов находится в папке C:\Program Files (x86)\Common Files\Adobe\Linguistics\5.5\Providers\Plugins2\AdobeHunspellPlugin\Dictionaries\ru_RU, и это набор из OpenOffice. Набор образца 2008 года. Даже те­сти­ровать не пришлось, все и так понятно: в идеале, при отсутствии ошибок в реализации, надеяться на ре­зуль­тат лучший, чем тот, что получен год назад (см. запись от 08.05.2010), не приходится.

Я не случайно упомянул об ошибках реализации. Следующий шаг, который я сделал, состоял в замене штатного набора паттернов из OpenOffice на набор Александра Лебедева. Полученный результат оказался неожиданным и требует самой серьезной проверки. Как только такая проверка будет проведена, сразу же сообщу.

Дело в следующем. Корректность переносов – условие необходимое, но, к сожалению, не достаточное... Нет сомнений, что рано или поздно ценой невероятных усилий, воспользовавшись самым мощным ком­пью­тером и наиболее полным словарем, удастся сформировать набор паттернов, который обеспечит безошибочность переносов. Но будет ли это решением задачи? Формально – да. Ошибок ведь нет...

А если взглянуть на этот вопрос с точки зрения читателя? Ответ будет иным. Читателю нужны не просто правильные, но комфортные переносы. Когда-то я написал, что в сложных словах типа "автомотовелофото" хотелось бы видеть в книгах переносы "авто-мото-вело-фото" и не хотелось бы – "ав-томо-тове-лофо-то"... В обоих случаях переносы правильные, но в первом – слово воспринимается легко, во втором – требуются дополнительные усилия.

Данная задача не может быть решена средствами TeX. Более того, она не решается любыми алго­рит­мами, не выполняющими морфологического анализа переносимых слов. Здесь необходимо отметить, что без под­держки со стороны программы верстки решение данной задачи невозможно в принципе. Поэтому я и обра­тился к InDesign. Ни одна другая программа верстки не способна справиться с задачей.

Поддержка нескольких уровней предпочтения для переносов была заложена в алгоритм BaH с самого начала разработки, но, поскольку в InD использовалось то же ядро, что и в Corel Ventura, приходилось этой возможностью жертвовать. С выпуском ядра 2-го поколения в Ultimate Edition BaH эта возможность будет наконец-то реализована.

Для чистоты эксперимента не применяется никаких сторонних утилит, используются только встроенные возможности ОРФО: словарь загружается в "ОРФО Редактор" и дается команда расставить переносы.

Переносы расставляются медленно: на компьютере с Core i5 3.47 ГГц мне понадобилось около 6 часов. (Для сравнения: консольная версия BaH справляется с этим же словарем за 4 секунды.)

Меняю в файле расставленные ОРФО мягкие переносы на дефисы. Меняю имя файла на orfo-2010.txt

Загружаю с Сайта протокол тестирования от 2005 года. В 2005 г. при тестировании исполь­зовалась система переносов ОРФО образца 1995 года. Меняю имя файла на orfo-1995.txt. Выполняю команду:

FC /B orfo-2010.txt orfo-1995.txt

Получаю:

Comparing files orfo-2010.txt and orfo-1995.txt

FC: no differences encountered

За 15 лет не исправлено ни одной ошибки... Это плохо. Но есть и хорошие новости: 30 ноября пред­ста­вители "Информатика" забрали c Cайта протокол тестирования от 2005 года. Очень хочется, чтобы люди внимательно его изучили и сделали правильные выводы...

Откладывать не стал. Купил "Коммерсантъ" № 110 / П от 30 июня 2008 г. Посмотрел по дороге домой, пересмотрел еще раз дома. Первое впечатление – уровень высок. А приглядишься и видишь – так себе, средненький. Есть нелучшие варианты, есть откровенные ошибки: "автос-вет", "выз-вать", "выг-лядел", "вып-лачена", "изб-ранного", "инвестп-рограмма", "Ингосст-раха", "исп-равления", "оз-наменовавшее", "ог-раничительные", "пов-торить", "подс-четами", "соб-ранной", "сов-ладельцы", "сос-лавшись", "спецп-риза", "Новосибирскэ-нерго", "электроэ-нергетики", "Татс-пиртпрома"...

Все на этом и закончилось... Больше возвращаться к этой теме я не планировал.

Однако ровно через год попался мне на глаза опрос А нужны ли вам переносы?, который инициировал наш коллега JAW. В предпоследнем сообщении (Июн 18, 2009 6:58 pm) дискуссии по данной теме был затронут вопрос о качестве переносов в газетах: "Посмотрите современные газеты – как в них переносят? Там админам что – лениво плагин в версталку поставить? Или галочку включить? Не так уж легко это сделать, русский язык зело сложен."

Поскольку все это осталось на уровне эмоций, ничего конкретного сказано не было, никаких фактов приведено не было, и, вспомнив про свой опыт оценки переносов в "Коммерсанте" от 30 июня 2008 г., я решил повторить исследование, но уже не ограничиваться одним изданием. Дело было вечером, газетные киоски в большинстве своем либо опустели, либо просто закрылись, но несколько пристойных изданий купить все же удалось. "Желтую" прессу из рассмотрения я сознательно исключил. В общем, в "турнире" при­няли участие:

"Коммерсантъ", 23 июня 2009 г. № 110 (№ 4165 с момента возобновления издания);

"Российская газета", 23 июня 2009 г. № 112 (4936);

"Ведомости", 23 июня 2009 г. № 113 (2383);

"Независимая газета", 23 июня 2009 г. № 124 (4756);

"Новые Известия", 23 июня 2009 г. № 105 (2698);

"Правда", 23 июня 2009 г. № 65 (29407);

"МК", 23 июня 2009 г. № 133 (25085).

Перечисляю издания в том порядке, в котором, как мне представлялось, они должны были бы "прийти к финишу". Конечно, издания различаются по объему, и сравнивать абсолютное количество ошибок было бы не совсем корректно... Но до количественного сравнения дело даже не дошло... Участники "соревнования" сразу же разделились на две группы: в одной все благополучно, и во второй – просто никак, соблюдением Правил в этих изданиях себя не утруждают.

Результаты, показанные участниками, меня поразили. Я не ожидал ничего подобного!

В лидерах – "Правда"! Ни одной ошибки в переносах на 4 полосах формата A2. (В двух случаях: "поз-воляла", "вне-сли" – я переносил бы иначе, но это дело вкуса.)

На 2-ом месте "МК". Всего 4 ошибки ("здравоох-ранения", "ме-дучреждения", "правоо-хранительного", "своев-ремен­ного") на 12 A2!

3 и 4 места поделили "Новые Известия" и "Независимая газета": ("ог-лядываться", "ог-раничивать", "оп-рошенных", "ох-ранник", "по-стуниверситетское", "уз-нает", "ук-ладывается", "ус-тановлено", "ус-тановлен­ные", "Хер-тогенбосхе") и ("ар-тобстрелу", "безо-бидного", "безо-пасности", "долгост-рой", "иност-ранных", "инфраст-руктуры", "Минз-дравсоцразвития", "обст-релу", "Оп-рашивали", "пост-радавших").

"Коммерсантъ", "Ведомости", "Российская газета" на 5, 6 и 7 местах. В них очень много ошибок; перечислить все их нет никакой возможности. Скажу лишь, что в "Коммерсанте" исправлено более 50 переносов (вот уровень их качества: "Великоб-ритания", "генп-рокурор"... ); в "Ведомостях" – тоже около 50 ("неэ-ффективной" – такой вариант и представить-то невозможно. Однако переносят. Понятно, что коррек­тор верстку просто не смотрел...) Ну и хуже всех дела в "Российской газете". Почти 100 правок в переносах – характер ошибок позволяет предположить, что при подготовке издания использовали InD CS2 + Proximity.

Причина, по которой эта работа была проведена, – в очевидном, говоря мягко, несоответствии притязаний и реальных результатов. С одной стороны, утверждается, что это "один из наиболее совершенных на сегодняшний день алгоритмов" и "несмотря на то, что алгоритм был разработан 25 лет назад, он до сих пор актуален, и его не удалось превзойти", с другой – я провожу тестирование и своими глазами вижу, что для русского языка даже с использованием таблиц Александра Лебедева, по-видимому, лучших на сегодняшний день канонических таблиц с правилами переносов, число ошибок совсем не мало, а по сравнению с bah результат и вовсе скромный: на одну ошибку bah приходится от 40 до 50 ошибок TeX... Причем речь идет не о лингвистических разногласиях и предпочтениях, а именно об ошибках, когда для каждого случая можно указать пункт Правил, который нарушен.

Чтобы не быть голословным: "Арт-обо-лев-ский", "ар-ту-дар", "Бит-лз", "буху-чет", "зме-ехвост-ка", <...>, "пэт-эуш-ник", "пя-тио-кись", "ра-зво-нял-ся", "ра-ди-озвез-да", "ра-диой-од-те-ра-пия", <...>, "фи-на-гент", "эф-фект До-ппле-ра", "юж-ной-е-мен-ский"<...> Водится и еще один грех за си­сте­мами переносов, в основу которых положена TeX-идеология. Почти все из них (таблицы Александра Лебе­дева в данном случае являются при­ят­ным исключением) ставят лишь часть из возможных переносов. "Образцом" здесь, пожалуй, является решение от Aextra Software для QXP 7.5 и 8. (Последствия этого ясны: отсутствие части переносов неми­нуемо должно приводить к дырам в верстке, устранять которые придется с помощью по­ста­новки дис­крет­ных переносов.)

Готовых ответов на возникшие вопросы мне найти не удалось. Связано это, скорее всего, с тем, что ори­ги­нальных алгоритмов расстановки переносов вообще не много, а уж таких, которые превосходили бы по качеству переносы TeX, кроме BaH просто нет... В общем, надо самому разбираться и начать, безусловно, следует с того, что четко уяснить, что алгоритм TeX не является алгоритмом расстановки переносов в прямом смысле слова. Имеется в виду следующее. Подход к расстановке переносов в TeX трехэтапный. На первом этапе любым из возможных способов в некотором словаре расставляются переносы. Лянг и Кнут рекомендовали привлечение к этой работе экспертов-филологов. На втором этапе с помощью специальной компьютерной программы, назы­вае­мой генератором паттернов, формируется набор определенным обра­зом устроенных последова­тельностей символов (паттернов), который позволяет воспроизвести исходную расстановку переносов. На третьем этапе, с которым мы, как правило, и имеем дело, построенный набор паттернов используется для расстановки переносов в прикладных задачах, например в издательских системах.

Критичными с точки зрения качества переносов являются первые два этапа. Понятно, что переносы в словаре должны быть расставлены идеально, но что менее ясно – а каков же должен быть размер этого словаря, чтобы получить заданную точность переносов (соотношение правильных и ошибоч­ных переносов)? Нет ясности и в вопросе отбора слов для такого словаря. И, конечно, генератор паттернов... Программа должна работать исключительно быстро и обладать достаточной разрешающей способностью, чтобы для схожих случаев генерировать разные паттерны. Обратите внимание, что, например в словах "суженый" и "суженный" решение о постановке переноса между буквами "у" и "ж" можно принять только, зная сколько "н" в слове... И это далеко не самый сложный случай...

В поисках ответов на интересовавшие меня вопросы я решил следовать не букве, но духу TeX-подхода. Я не стал использовать стандартную версию генератора паттернов, которая применяется с времен Лянга... Написал свою собственную. По ряду причин. Главная – Лянг не ставил задачу достижения 100%-правиль­ности переносов в словаре большого объема. Наоборот, при формировании словаря, по которому он строил набор паттернов, редкие слова отбрасывались, чтобы не искажать типичную картину. Скорее, реша­лась задача, как минимальным объемом кода и минимальными затратами времени обеспечить пра­виль­ный перенос наиболее распространенных слов. Меня же интересовало иное. (О точности расста­новки переносов, исключающей вмешательство корректора, я не говорю. Это и так ясно.) Главный вопрос: кто сильнее: bah в классической реализации или bah, формирую­щий и затем использующий паттерны? Ответ, вроде бы, очевиден. Но сама по себе задача увлекательная. Имея один и тот же исходный словарь, оценить возможности разных подходов за пределами исходного мно­же­ства слов. Итак, "сила" или "ум"?

Это, конечно, шутка... Но вопрос-то действительно серьезный, философский: до каких пор можно отбра­сы­вать качественную сторону рассматриваемого явления и ограничиваться чисто количественным, мате­ма­тическим подходом? Свести слово, устроенное по определенным правилам, к набору символов и черточек... Ни гласных, ни согласных, ни приставок, ни суффиксов...

...первый шаг – использование готовых таблиц паттернов. Это просто. Было сделано два месяца назад. С генератором паттернов сложнее. Особенности решаемой задачи изменили "облик" паттернов: они мало походят на паттерны Лянга. Но полностью понятны TeX. То есть, "Liang compatible"... Исходный словарь восстанавливается полностью. Серьезной проблемой является время, необходимое для построения набора паттернов... И здесь можно высказать первое предположение относительно не очень высокого качества доступных таблиц. Почти все они созданы в годы, когда производительность компьютеров была мала. А без словаря большого объема о качестве таблиц говорить сложно. В начале своих экспериментов я работал с небольшими словарями. Есть у меня словарик на 60000 знаков, содержащий исключи­тельно сложные случаи переносов. Построил я по нему набор паттернов, применяю – словарь воспро­изводится на 100%... И даю простейшее слово, не входящее в использованный словарь, – "собака"... Не переносится вообще... Вот вам и ответ на вопрос, почему алгоритм от Aextra Software ставит лишь часть переносов...

Здесь следует заметить, что в своих опытах я не сталкивался со случаями, чтобы ограничение объема приводило к постановке неправильных переносов... До поры, до времени... Если же использовать таблицу паттернов, сгенерированную по словарю небольшого объема, для расстановки переносов на большом словаре, результат непредсказуем... Я провел испытания идеальной таблицы (с точки зрения небольшого словаря) на словаре, превосходящем в 50 раз исходный. Результат ужасный... Знакомые слова переносятся правильно, на неизвестных алгоритм предлагает самые "дикие" варианты. При этом обуздать "дикость" не­возможно. Ее можно лишь задавить... использовав для генерации паттернов словарь большого объема... И если классический bah на совсем уж незнакомых словах и может дать неправильный вариант переноса, то лишь неправильный, но не "дикий"... Конечно, 50-кратное расхождение в объемах – случай предельный... Но именно в таких условиях и удается понять потенциал алгоритма.

Сегодня я не могу дать каких-то конкретных рекомендаций по формированию словаря, оптимального с точки зрения построения набора паттернов. Пока исхожу из того, что он должен быть настолько большим, насколько позволяют вы­чис­лительные возможности. Я, например, переписал генератор паттернов под MAC OS только потому, что мой iMac процентов на 40 быстрее имеющихся в моем распоряжении PC.

19.01.2009  02:22

Завершен первый этап. На словаре, содержащем 256000 словоформ, варианты переносов обеих версий BaH совпали абсолютно... Было время, когда я сомневался в возможности создания таблицы паттернов, способной повторить результат классической версии. Можно. Теперь предстоит самое интересное... Выход за пределы исходного множества слов.

20.01.2009  03:06

Эйфория дня вчерашнего – все-таки переносы в большом словаре да и слов не самых простых вос­про­из­ведены абсолютно точно – сменилась на глубочайшее уныние... Применил полученную таблицу паттернов к громадному словарю, вдвое превышающему тот, по которому паттерны строились... 584000 словоформ... Провал полный (на мой взгляд, конечно). На словах незнакомых сплошные проколы... И самое грустное, что это проявление именно TeX-подхода. Вот три "близких" слова: "абортарий", "портартуровец", "спортарена", включающих цепочку символов "ортар"... И вот результат: "аборт-а-рий", "порт-ар-ту-ро-вец", "спорт-аре-на"... Причина – в словаре, по которому строилась таблица паттернов, не было слова "абортарий"... Для тех же слов и таблиц Александра Лебедева имеем: "абор-та-рий", "пор-тар-ту-ро-вец", "спор-та-ре-на"... Очевидно, что словарь, с которым работал Александр Лебедев, не содержал слов "портартуровец" и "спортарена"... Излишне говорить, что BaH-Classic справился со всем этим легко... По-моему, TeX-подход безнадежен... Можно, конечно, строить таблицы по словарю бесконечного объема, что, понятно, потребует бесконечного времени... Вот тогда результат будет идеальным...

21.01.2009  02:59

Опять появилась надежда! Как оказалось, можно построить несколько разных наборов паттернов по одному и тому же исходному словарю, которые на этом словаре будут давать 100%-совпадение результатов, но за его пределами качество расставляемых переносов будет различаться значительно. Сейчас исследую разные варианты генератора паттернов. Постепенно продвигаюсь к желаемому. В качестве "побочного" эффекта пробую формулирорвать требования по отбору слов для словаря. Совершенно точно не следует включать в него все подряд... Это будет лишь приводить к увеличению времени работы генератора. И, на мой взгляд, не стоит вручную редактировать таблицы паттернов. При всей заманчивости и кажущейся легкости такого подхода от него следует отказаться. Результат такого вмешательства в общем случае предсказать нельзя... Исправление в одном месте может породить проблемы там, где их совсем не ждешь.

Я продолжаю эксперименты......

Вкратце об особенностях первых семи таблиц рассказано Александром Лебедевым в Комментарии к выпуску новых таблиц переносов ruhyphal.tex.

Я же подробный отчет о проведенных испытаниях постараюсь подготовить в новогодние каникулы... Здесь нельзя просто ограничиться указанием на то, что та или иная таблица лучше или хуже... Мне хочется понять, почему все-таки не получено на этом пути решения, затмившего все прочие и навсегда закрывшего проблему переносов для русского языка. Где проходит граница между возможностями алгоритма и особенностями реализации? Почти двадцать лет таблицам Вулиса... Как минимум представлено девять попыток решения проблемы... А результат все еще далек от идеального...

Тестирование алгоритма проводилось с использованием InDihyphCS3 – плагина для Adobe® InDesign® CS3. Качество переносов плагина и систем QXP75 и QXP8 практически совпадают... Единственное отличие: в InDesign'е в четырехбуквенных словах переносы расставляются... В кварковских реализациях – нет.

Что можно сказать по результатам испытаний? Ошибок первого рода (постановка неправильных пере­но­сов) алгоритм Aextra Software делает немного. В основном это ошибки в сложносокращенных словах, что простительно: нельзя знать всё... Но встречаются среди них достаточно странные случаи: слово "майор" алго­ритм переносит правильно: "май-ор". Но "брандмайор" – с ошибкой: "бранд-ма-йор". Что же касается ошибок второго рода (непостановки правильных переносов), таковых много, а понять их причину не­просто. Почему, например, в слове "иезуитствуют" алгоритм предлагает лишь один вариант: "иезу-итствуют" – да и тот не самый лучший? Про "сестра" и "сестры" уже говорилось на ProDTP. Вот еще примеры: "змее-хвост-ка" и "змее-хво-стки", "из-ру-гают" и "изри-суют"...

Результаты, показанные плагином как с mshy3ru.dll, так и с inhy32ru.dll, совпали абсолютно: ошибка в переносе слов, пишущихся через дефис, осталась. В этом нет ничего удивительного: библиотеки работают правильно... Любой, умеющий пользоваться отладчиком, легко в этом убедится...

Что бы ни говорили, ошибка в коде плагина. Но не это главное. От ошибок в программах застраховаться невозможно. Смущает другое. Об ошибке известно почти полгода. Исправить ее – дело минутное. Давно уже можно было это сделать и забыть о ней... И то, что этого не происходит, сдается мне, есть оборотная сторона бесплатности, за которую так многие ратуют...

Отличий в работе версий для CS2 и CS3 не выявлено. То есть ошибка в переносе слов, пишущихся через дефис (примеры см. в разделе, посвященном dash.pln для CS2), не устранена. Поскольку результаты, показанные обеими версиями, полностью совпадают, протокол испытания версии для CS3 в архив я добавлять не стал...

А причину ошибки я все-таки установил. Много было разговоров по поводу того, кто же виноват – библиотека или плагин... Для себя я ответ нашел – плагин.

Как показал анализ, с точки зрения качества переносов Demo-версия эквивалентна версии коммерческой и после минимальной "доработки" может быть использована для полномасштабного тестирования... Что и было сделано (см. раздел Сравнить, Протоколы тестирования.).

Но, прежде чем приступать к изучению протокола тестирования, я всем рекомендовал бы познакомиться с идеями, положенными в основу технологии, и прочитать *TALO's LANGUAGE TECHNOLOGY. Без этого трудно будет понять причины ошибок, совершаемых алгоритмом. А они очень интересны и нетипичны: "ан-ар-хия", "ан-тияд-ро", "ап-ел-ля-ция", "ап-ель-син", и т. п.

Самое первое впечатление от увиденного – удивление: вновь пишущиеся через дефис слова переносятся неверно. И это уже третий случай на пять исследованных программ! Только на этот раз ошибка гораздо серьезнее: все переносы после дефиса сдвигаются на одну позицию влево... Возникает вопрос: а вообще-то разработчики тестировали свое творение? И как можно было не заметить такое: "або-ри-ген-=и-нд-еец", "аб-стракт-но-=гра-мм-ат-ич-еский", "авиа-цион-но-=а-рти-лл-ери-йский" и т. д.

Безусловно, ответственность за качество программ целиком лежит на разработчиках, но справедливости ради следует отметить, что в этих ошибках есть и доля вины Adobe Systems Inc. Если из пяти разработчиков трое допускают ошибку в одном и том же месте – это не случайно. Слишком сложна и громоздка система, SDK содержит ошибки...

Так вот, обнаружилось, что слова, пишущиеся через дефис, являются камнем преткновения и для dash.pln. Причем понять, какие же именно особенности реализации могут приводить к подобного рода ошибкам, достаточно сложно. Ср., например, "або-ри-ге-н=ин-де-ец" и "або-ри-ген=пиг-мей"... На фоне таких ошибок все прочие различия в результатах кажутся незначительными. Интересующимся рекомендую пословное сравнение протоколов тестирования...

6 января 2008 г., во время новогодних каникул, нашел я, в чем же причина такого поведения.

Если не обращать внимание на переносы одной буквы в начале и конце слова (см. комментарий к Winsoft), достаточно заурядный по своим возможностям алгоритм. Замечу, что до этого случая мне не встречались разработки, ставящие перенос перед "й" (см., например, "вы~~~й~дешь").

Иметь программу для Proximity и не применить ее для анализа качества алгоритма модуля Winsoft было бы непростительно. И хотя после первого, предварительного, исследования я решил не тратить время на оценку алгоритма Winsoft, но, подумав, понял, что погорячился. Переносы одной буквы в начале и конце слова хотя и не украшают алгоритм, но на практике не играют никакой роли, поскольку должны отсекаться InDesign'ом при задании минимального количества символов до первого и после последнего переносов в стиле абзаца.

Что немедленно бросается в глаза при исследовании протокола тестирования – неспособность алгоритма переносить слова, пишущиеся через дефис. Немало претензий можно было бы предъявить и к качеству работы. Например, алгоритм ставит переносы перед 'й', 'ъ' и 'ы': "вы~~~й~~~дешь", "без~ъя~~дер~~ный", "без~~~ы~~~дей~~ный"... Тем не менее, даже при таком невыдающемся качестве, в "боевых" условиях модуль от Winsoft превосходит Proximity. Но в условиях тестирования, когда выясняются максимальные возможности алгоритмов, обе разработки производят удручающее впечатление.

Больше года ходил я вокруг да около, не зная как подступиться к задаче. Нужна была идея. А ее-то и не было... Ну а появилась – дальше уже было дело техники... На собственно тестирование, правда, времени не осталось. Смог выделить два часа... Тут уже, конечно, не до изысков. Важно было получить результат... Из протоколов тестирования видно, что различий между версиями для CS2 и CS3 нет. Сравнение с другими модулями расстановки переносов пока вынужден отложить... Нет времени. Но каждый желающий сможет проделать это самостоятельно. Весь фактический материал для этого предоставлен...

Программу мне прислали по e-mail еще 26 апреля 2006 г., но только сейчас до нее дошли руки. Особого впечатления работа не произвела: алгоритм незатейлив, морфологического анализа слов не производится, в результате во всех сложных, сложносокращенных и словах с приставками, в которых можно было сделать ошибки, они и сделаны. Но есть и просто необъяснимые случаи: например, не переносится слово "Англия". Плохо, что при таком невыдающемся качестве непредусмотрено пользовательского словаря. Утилита поддерживает разметку текстового файла под все программы верстки. Но с модулями профессионального уровня для Corel Ventura 8, Adobe PageMaker 6–7, QuarkXPress 3–5 конкурировать не может. Остаются QuarkXPress 6, 7 и Adobe InDesign. Однако по моим представлением утилита сильно уступает Proximity.

Что касается работы утилиты, лаконичность ее сообщений удручает. Понять, чем занимается программа, абсолютно невозможно: выводится имя обрабатываемого файла и утилита погружается в себя. Ладно бы она надежно работала... Но на моем стандартном словаре, размером 2996978 байт, программа через несколько минут работы слетает без объяснения причин. И только если словарь разбить на два файла, удается получить результат. Протокол тестирования утилиты можно найти в разделе Сравнить.

И еще из области мистики – появление лишней скобки перед "ро":

Работу утилиты с текстами на украинском языке не проверял, соответственно, сказать ничего не могу.

Априори возможность автономного использования XTension'а совсем не очевидна. Скорее наоборот – задача представляется трудноразрешимой. Дело здесь вот в чем.

При оформлении модуля в виде классической DLL (как, например, в случае Corel Ventura, Adobe PageMaker...) такая возможность гарантируется и достаточно просто реализуется. Это объясняется тем, что "нормальная" DLL самодостаточна в том смысле, что весь необхо­димый для работы код находится либо внутри самой библиотеки, либо стандартным образом "достается" из других DLL. XTension же интегрируется в приложение; использует процедуры, находящиеся внутри приложения. В результате приходится решать непростую задачу разделения XTension'a и Quark'а. От того, удастся или нет распутать код, напрямую зависит возможность автономного использования XTension'а. Дополнительно проблема осложняется тем, что все XTension'ы экспортируют только одну функцию – _xtactivate_cb@4. Соответственно возникает необходимость локализации кода, отвечающего за выполнение главной части задачи... Но и это не самое страшное. Хуже, когда процедуры интенсивно используют глобальные переменные. Их как минимум надо правильно инициализировать, а для этого хорошо бы понимать их смысл...

В общем, повозиться со всем этим было бы здорово. Но вот время... Где его-то взять? Смог выкроить лишь пару дней – сделал только часть запланированного. В случае russhyph.xnt с задачей удалось справиться сравнительно легко. Пришлось, правда, для фрагмента кода, корректирующего обработку сдвоенных букв и удаляющего переносы перед й, написать функциональный аналог, но это мелочи. В случае же autodash.xnt из-за использования глобальных переменных, о чем говорилось выше, пока не удается построить автономный вариант модуля. Но, если время позволит, постараюсь дожать...

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

Началось все достаточно неожиданно, а развивалось стремительно. Еще накануне планы на 3 октября были у меня совершенно иными. Но позвонили из одного дружественного издательства и попросили взглянуть на публикацию, подготовленную в пятой версии Quark'а внештатными сотрудниками. Посмотрел. Внешне все выглядело очень прилично. Тут бы мне и остановиться. Так нет, уже по привычке обращаю внимание на переносы. Вроде бы, все нормально, без единой ошибки. А это уже подозрительно: скорее всего, корректоры поработали на совесть. Копаю глубже. Вношу минимальную правку – пошла переверстка... И вот он момент истины. С ходу натыкаюсь на из-ящный. Смотрю далее: треу-гольный, на-иболее, раз-ум, аванс-цена... Конечно же, захотелось узнать, что за чудо-инструмент использован для расстановки переносов. Ищу в Сети, – наверняка ведь оттуда брали – что же предлагается для QuarkXPress 5.0. Так, Autodash (1.6.6) и RussHyph 2.0. Начинаю с autodash.xnt. Ставлю, смотрю. Точно он... Много сил люди вложили в отделку, основная же функция не дотягивает даже до среднего уровня. Что понравилось в программе, так это дополнительный сервис: Help и режим отладки, визуализирующий все расставленные переносы в блоке или выделенном фрагменте. В общем, фантик хорош, конфетка же – так себе.