Отвечаю за каждый пе-ре-нос...

Очень долго почти во всех программах вёрстки отсутствовал модуль русских переносов. Но что за вёрстка без переносов? К счастью, всегда находились энтузиасты, создававшие программы для их расстановки. Результат часто оставлял желать лучшего, но с этим приходилось мириться.

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

Долгое время альтернативой штатным средствам расстановки переносов оставалась Ylab. Опираясь на технологию Microsoft (Informatic), она обеспечивала приемлемое качество, что позволяло снизить остроту проблемы. Но, как и инструменты от Adobe, безупречной работу Ylab назвать нельзя.

Приблизиться к цели удалось лишь в конце 2007 г., когда появился batov’s hyphenator for Adobe InDesign CS2/CS3, созданный Игорем Батовым. Сейчас модуль превосходит по качеству расстановки переносов все известные разработки. В сравнении со штатными Proximity и Winsoft расширение BAH в настоящее время имеет одно ограничение — работает только на платформе PC. Реализация для Mac OS — дело будущего.

Кроме безупречной расстановки переносов следует отметить и наличие обратной связи с разработчиком. Устранение недоработок (ошибок, неблагозвучий и т. п.), как правило, занимает не более недели — в очередном обновлении, которые выходят по понедельникам, их уже нет. Если вы пытались связываться со службой поддержки Adobe, в надежде исправить замеченную ошибку, оцените оперативность улучшения модуля.

А если взглянуть на подобные расширения с точки зрения разработчика? Может, количество попыток разной степени успешности — признак того, что это далеко не простая задача? Как пользователи, мы видим только результат, но как он достигается? Как принимаются решения о выборе того или другого положения переноса? Об этом и многом другом мы беседовали с создателем модуля ВАН.

Когда-то была передача «Это вы можете», обычно начинавшаяся вопросом «Как Вы дошли до жизни такой?».

За начало отсчёта, наверное, правильно будет принять 1992 г., когда я пришёл работать в издательство «Литературная газета». Времена были интереснейшие. Всё только начиналось, опыт применения компьютеров в издательской практике у всех был нулевой. Да и сами компьютеры были в диковинку. В Московском университете, в лаборатории, где я до этого работал, был всего один компьютер — Amstrad PC1640 c 9-игольчатым матричным принтером. В издательстве же мне продемонстрировали парк 386-х машин, принтеры QMS с PostScript, фотовывод… Но главным чудом казались 19-дюймовые мониторы Sigma LaserView. Подготовка изданий выполнялась в программе Xerox Ventura Publisher 2.0.

Безусловно, Ventura — выдающаяся система, удручало лишь качество модуля переносов, включённого в русифицированную версию. Из массы ошибок запомнилось «пол-иция»… Примера достаточно, чтобы составить представление об общем уровне разработки. С той поры и до дня сегодняшнего тема переносов остаётся актуальнейшей для всех издательских систем. Предлагались разные решения, но никогда не было такого, чтобы вообще забыть о переносах, чтобы стало как в здоровом теле — не чувствуешь же, например, сердце, когда оно в порядке.

Самое грустное, что многие перспективнейшие разработки, которые в других условиях можно было довести до совершенства и закрыть проблему переносов навсегда, не пережили нашествия «неплательщиков». Счёт покупателям систем расстановки переносов шёл на единицы. Кроме издательства «ЭКСМО», сейчас никого и не вспомню. Так и ушли в историю UniSpell и Russian Language Extender… А к моменту появления Corel Ventura 8 желающих сделать для неё систему переносов уже не осталось. Могли ещё многие, но не хотел никто.

Пришлось самому приниматься за работу. Конечно, я никак не предполагал, что работа растянется у меня на всю жизнь. Хотелось-то всего-навсего нормально готовить к печати книги в новой программе. Создание системы расстановки переносов было для меня задачей вспомогательной, и отводил я на её решение максимум полгода, но не учёл того, что работу начинаю в «голом поле» и полной изоляции… Главной проблемой оказались словари. Сегодня их легко найти в Сети или, например, загрузить с моего сайта http://www.batov.ru/ — причём не только их, но и образцы того, как должны выглядеть в этом словаре переносы. Тогда же пришлось всё создавать с нуля.

Несмотря на все сложности, через 4 года система была в основном готова. А применялась на практике c самых первых дней: в 90-е годы я тесно сотрудничал с ЭКСМО, где работали очень сильные корректоры. С каждой подписанной в печать книгой количество ошибок в программе неуклонно сокращалось. И наступил момент, когда корректоры перестали находить ошибки в изданиях, подготовленных с помощью моей программы. Это была победа. Но одновременно возникли и новые трудности. С этого момента в деле тестирования корректоры мне уже не могли помочь. Развитие алгоритма требовало нового подхода к тестированию в случае редко встречающихся словоформ. Постепенно с проблемами удалось справиться, а теперь всё это уже в прошлом.

Сегодня, как пользователя, разработка меня устраивает абсолютно. То, что требуется от системы расстановки переносов, она делает очень и очень хорошо. Но, как разработчику, мне хотелось бы многое добавить. Хотя, по большому счёту, это уже украшательство. Здесь главное — вовремя остановиться, не перегрузить систему массой ненужных функций.

Есть Правила переносов в редакции 1956 г., а есть жизнь языка, какие-то тенденции в обществе к упрощению правописания. Это как-то влияет на совершенствование алгоритма?

Говоря о тенденциях (я берусь судить лишь о том, что относится к расстановке переносов), я бы отметил существование двух встречных потоков. Один нашёл выражение в «Своде правил русского правописания. Орфография. Пунктуация», подготовленном в 2000 г. в секторе орфографии и орфоэпии Института русского языка им. В. В. Виноградова РАH. Если коротко, предлагалось предельно упростить правила: сохранив 4 строгих запрета, во всех прочих случаях предоставить пишущему право использовать любой вариант переноса: 1) нельзя отделять часть слова, не составляющую слога; 2) нельзя отделять гласную от предшествующей ей согласной; 3) нельзя оставлять в конце строки или переносить одну букву; 4) нельзя переносить часть слова, начинающуюся с букв ‘ъ’, ‘ь’.

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

Конечно, крайние взгляды на способы переносов присутствовали всегда. Например, кто-то выдвигал требования не разделять «бл», «вл», «мл», «пл», «фл», «жд». Другие полагали, что нельзя разбивать переносом суффикс «ющ». Есть и такие, кто уверен, что нельзя разбивать сочетания «дж», «кс». М. В. Шульмейстер считал, что существующие в некоторых типографиях списки сочетаний согласных, не подлежащих разделению при переносах, ничем не обоснованы.

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

Как известно, правила в языке закрепляют определённые нормы определённых групп определённого времени. Они не конструируются и не выдумываются. Соответственно, разработка и развитие алгоритма проходят в диалоге и сотрудничестве со всеми заинтересованными сторонами. Но к ним я отношу и тех, кто жил до нас, — за них говорят книги, которые они оставили после себя. Их видением того, как быть должно, руководствуюсь в первую очередь. Конечно, и 30, и 50 лет назад взгляды людей могли расходиться. И приходилось выбирать. Но выбор этот был между хорошим и лучшим!

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

В изданиях середины прошлого века и нынешних есть слова, переносящиеся по-разному, аргументы имеются в пользу каждого варианта. Например, «из-учить» и «изу-чить». Какое решение принимает Ваш алгоритм в таких сложных случаях?

Если ответить коротко, приоритет принадлежит морфологическому принципу. Применительно к данному случаю — выбирается «из-учить». Только я бы не рискнул утверждать, что оба варианта можно встретить в книгах. Точнее, вариант «из-учить» мне не встречался ни разу. Но это один из тех немногих случаев, когда при принятии решения о положении переноса традиция была подчинена Правилам и требованию унификации. На мой взгляд, вариант переноса не должен зависеть от вида приставки. То есть для меня более приемлемы варианты: «из-учить», «об-учить», «вы-учить», «до-учить», «за-учить», «на-учить», «пере-учить», «про-учить».

Когда у меня возникала проблема с выбором варианта постановки переноса, я обращался к изданиям, которым доверяю. Просмотрев огромное количество книг, выпущенных с начала 50-х до конца 70-х годов (я сознательно ограничился подготовленными в докомпьютерную эру), остановился на книгах издательств «Детгиз», «Мысль», «Искусство». Таким образом, я заочно консультировался и консультируюсь с огромным числом корректоров и редакторов. Периодически обращаюсь к БСЭ. В ней, например, нашёл подтверждение правильности вариантов «Ленин-абад», «Сталин-абад», которые и зафиксированы в алгоритме, начиная с версии 1.09. Если возникала необходимость в расстановке переносов в терминах математических, химических, медицинских, я обращался к изданиям из этих предметных областей. Традиция, закреплённая в них, переносилась в алгоритм.

Возвращаясь к предложенной вами дилемме: я абсолютно не настаиваю на варианте «из-учить», а лишь предлагаю читателям и издателям высказаться по данной проблеме. Если большинство предпочтёт классическое решение, оно и будет окончательно закреплено в алгоритме.

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

Достоинство у выбранного способа регистрации (защитой такую систему можно назвать с большой натяжкой), пожалуй, одно: удаётся избежать привязки программы к «железу». Но, в принципе, любые системы защиты, регистрации создают для пользователя некоторое неудобство. Функционирует это так.

При каждом запуске Adobe InDesign CS3 модуль сообщает на сервер, что приступает к работе. Никакая другая копия, запущенная после этого от пользователя с тем же именем, расставлять переносы не будет. То есть для каждого кода доступа на нескольких машинах, подключённых к Интернету, в данный момент времени активной может быть только одна копия. Так реализуется привязка программы не к «железу», а ко времени. Мне, поскольку я сам много готовлю книг к печати и все решения примеряю на себя, такой режим представляется комфортнее. Приобретя всего одну копию, можно работать с ней на любом компьютере. Не надо волноваться по поводу апгрейда, переустановки ОС и т. п. А при привязке к «железу» приходится приобретать столько копий программы, на скольких компьютерах вы планируете её использовать.

Поэтому: если приобретён один модуль, при переходе на другой компьютер необходимо заново регистрировать свою копию модуля на сервере (запуская каждый раз setup_cs3.exe в случае Adobe InDesign CS3). Уходит на это секунд 40.

В чём суть обновлений программы? Ведь Вы её писали больше 10 лет — откуда же еженедельные релизы?

В действительности все эти годы программа обновляется ежедневно. Но поскольку сегодня поддерживается несколько версий, необходимо перед выпуском коммерческой провести полное тестирование всех. На это уходит два полных дня — суббота и воскресенье. Причин же, по которым обновления выходят столь часто, две.

Во-первых, я не выношу ошибок… Мне легче их исправить, чем уговорить себя подождать, когда будут найдены и другие неточности, чтобы устранить всё за один раз. Ведь если можно исправить немедленно, почему этого не сделать?

Во-вторых, когда 4 года назад я создавал сайт, то высказал пожелание: «В конце концов, модуль переносов не ОС, и если не каждый день, то хотя бы раз в неделю можно было бы получать обновление». Теперь вот стараюсь поставить дело так, как когда-то представлялось мне правильным.

Как организовать работу с программой, если вёрстка отдаётся на сторону?

Установить аналогичный модуль на второй машине.

Обновления могут стать причиной того, что в работе, сделанной год назад, изменится расстановка переносов, если будет активен последний модуль?

Здесь надо понимать правильно: обновление — другой продукт. Со всеми вытекающими отсюда последствиями. Конечно, предыдущая и новая версии близки и процент изменений не будет велик, но всё-таки это разные продукты. Обычно удаётся очень быстро привести публикацию к прежнему виду. Но лучше всего сохранять предыдущие версии модуля.

На сайте я уже обращал внимание пользователей: новая версия устанавливается поверх старой, поэтому перед установкой новой версии старую следует сохранить. Можно, например, перед обновлением переименовать файл bah.pln в bah.107, bah.108 и т. п., а хранить в той же папке, где располагается работающая версия. Это удобно: не надо искать или запоминать, где хранится архив… Восстановить предыдущую версию столь же легко: переименовать файл из bah.107 в bah.pln. Но лично я предпочитаю переверстать работу под новый модуль.

Как предполагается развивать программу?

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

Но даже если всё пойдёт не так, как хочется, и проект придётся закрыть, я отнесусь к этому спокойно. То, что хотел сделать, уже сделал: BAH установил новый стандарт качества для систем расстановки переносов. Теперь всякая новая разработка будет просто обязана превосходить BAH. Тогда мы никогда уже не встретим в книгах столько ошибок в переносах.

Пока правят бал халявщики, проще украсть или взломать, чем купить. Не боитесь, что найдётся умник, которому всё равно, что «хакнуть»?

Теперь уже не боюсь. Но ещё год назад не исключал такой возможности. Это даже привело к тому, что выход модулей задержался на несколько месяцев: решено было снабдить разработку системой защиты от несанкционированного распространения. Написал по всем правилам… и пришёл в ужас от нелепости и несоразмерности получившегося. Меры по охране, которые больше подошли бы для защиты государственной границы, применялись для обеспечения безопасности садового домика. Пришлось всё срочно переделывать. Но защита была интегрирована в разработку столь глубоко, что следы её пребывания можно видеть ещё и сегодня. В коммерческой версии осталось лишь небольшое декоративное заграждение.

А оказалось всё гораздо проще (правда, выяснилось это уже после начала продаж). Разработку ведь нельзя приобрести анонимно. Обязательно с потенциальным покупателем что-то обсуждаем, уточняем… И выяснилось, что между всеми купившими разработку очень много общего. Всё это люди успешные, состоявшиеся, занимающиеся серьёзными проектами. Почти всем около сорока или больше. Когда же я слышу: «умник, которому все равно, что хакнуть», в сознании рисуется совершенно иной образ. Я не могу представить, что человек, понимающий, что слова «суженный» и «суженый» следует переносить по-разному, будет что-то взламывать. Общий высокий уровень развития, культуры задаёт и стиль поведения, определяет представления о добре и зле…

Если же взглянуть на это с точки зрения рациональной, окажется, что рубить сук, на котором сидишь, можно только по недомыслию. Не думаю, что кто-либо после BAH захочет вернуться к Proximity. К хорошему привыкаешь быстро. А реальных альтернатив пока не видно. Это во-первых.

Во-вторых, на мой взгляд, ситуация сегодня уже не та, что в 90-е. Тогда всё-таки цены на программы и доходы реальных пользователей были несоизмеримы. При заработке в 100 долл. купить программу за 40 крайне сложно. Когда же зарабатываешь 1000 или 2000, это проходит легко и незаметно. Гораздо проще купить и жить спокойно.

К тому же это своего рода вложение в собственный завтрашний день. Когда для очередной версии, допустим того же InDesign, понадобится качественная система переносов, людям будет куда обратиться. И отправятся они не на форумы с вопросом: «Где взять переносы?» — а к конкретному разработчику… А если вы уверены, что всё необходимое будет, причём самого высокого качества, то и свою деятельность можно организовать и планировать совсем иначе.

Часто пользователи восполняют недостатки модулей переносов добавлением собственных словарей. А как с этим в модуле ВАН?

Работа со словарями здесь ничем не отличается от, допустим, Proximity. Проблем нет, но… и смысла нет. Словари — мера вынужденная, отражение нежелания разработчиков тратить силы на тестирование продукции. Сделали что-то — и скорее на продажу, какое уж тут тестирование… Забота о качестве просто перекладывается на плечи пользователей. И получается: каждый вынужден создавать свой словарь, практически не отличающийся от всех прочих, и с единственной целью — исправить ошибки разработчиков.

Для меня это абсолютно неприемлемо. Все должно быть с точностью до наоборот: надо не словари создавать, а исправлять алгоритмы. Иначе конца ошибкам не будет. Словарь необходим, если от разработчиков не получить поддержки. На мой взгляд, это безобразие, что Proximity из CS2 перекочевал в CS3 без единого изменения. Вот уж где работы непочатый край! Здесь без словаря пропадёшь.

Только в одном случае словарь оправдан — когда работать приходится в узкой предметной области. Например, при подготовке изданий по органической химии. Перекладывать обработку химической терминологии на алгоритмы, рассчитанные на работу со словарями общей лексики, далеко не лучшее решение.

Беседовал Михаил Иванюшин