Так сложилось, что очень долго во всех программах верстки модуль русских переносов отсутствовал. Но что за верстка без переносов? К счастью, всегда находились энтузиасты, создававшие программы, расставлявшие переносы. Качество работы этих приложений часто было не очень высоким, но за неимением лучшего приходилось довольствоваться тем, что есть.
Появление русских переносов в программе InDesign обрадовало всех: наконец-то можно не искать этот модуль, а сразу начать работать. Но скоро стало очевидно, что имеющееся расширение с задачей расстановки русских переносов справляется плохо. Фирма Adobe сменила разработчика — в последних версиях используются модули Proximity или Winsoft. Но и они допускают много ошибок. И нет никакой связи с разработчиками, чтобы сообщить о найденных ошибках в надежде получить с новым обновлением программу, свободную от замеченных недостатков. Хотя, если модуль переносов предлагает такие варианты, как аванс-цена, авто-рский, водонас-ыщение, военс-пец, всез-нающий, доб-росить, дог-рузить, инос-транец, при-нципиальный, сберк-нижка, спе-цо-деж-да, тихоо-кеанский, связываться с разработчиком, чтобы он усовершенствовал алгоритм, наверное, не стоит. Лучше поискать другое решение.
Долгое время таким решением — альтернативой штатным средствам расстановки переносов — оставалась разработка Ylab. Опираясь на технологию Microsoft (Informatic), она обепечивала приемлемое качество, что позволяло несколько уменьшить остроту проблемы. Но, как и инструменты от Adobe, задачу безупречной расстановки переносов не решала...
Приблизиться к цели удалось лишь в конце 2007 года, когда появился batov’s hyphenator for Adobe InDesign CS2/CS3, созданный И. В. Батовым. (Полную информацию об алгоритме Batov’s Hyphenator, сокращенно ВАН, можно найти на сайте разработчика http://www.batov.ru/.) На сегодня этот плагин превосходит по качеству расстановки переносов все известные разработки. В сравнении со штатными Proximity и Winsoft расширение BAH в настоящее время имеет одно ограничение — работает только на платформе PC. Реализация для платформы Macintosh остается пока делом будущего.
Кроме расстановки безупречных переносов следует отметить и наличие обратной связи с разработчиком. Устранение любых замечаний, встреченных ошибок, неблагозвучий, как правило, занимает не более недели — в очередном обновлении, которые выходят по понедельникам, их уже нет. Если вы пытались связываться со службой поддержки Adobe, в надежде исправить замеченную ошибку, то оцените оперативность улучшения этого плагина.
А что, если взглянуть на разработку этих расширений с другой точки зрения? Может, то, что так долго разные разработчики пытаются сделать эту программу, признак того, что это далеко не простая задача. Как пользователи мы видим только результат, но какими силами он достигается, как, например, принимаются решения о выборе того или другого положения переноса?
Именно поэтому редакция сочла уместным не просто рассказать о модуле ВАН, а побеседовать с его разработчиком.
Игорь Владимирович, когда-то была передача «Это вы можете», и часто первым вопросом был «Как Вы дошли до жизни такой?» Как бы Вы на этот вопрос ответили?
За начало отсчета, наверное, правильно будет принять 1992 год, когда я пришёл работать в издательство «Литературная газета». Времена были интереснейшие. Всё только начиналось, опыт применения компьютеров в издательской практике был у всех нулевой. Да и сами компьютеры были в диковинку. В Московском университете, в лаборатории, где я до этого работал, был всего один компьютер — Amstrad PC1640 c 9-игольчатым матричным принтером. В издательстве же мне продемонстрировали парк 386-машин, постскриптовские принтеры QMS, устройство фотовывода. Но главным чудом казались 19-дюймовые мониторы Sigma LaserView. Подготовка изданий выполнялась в программе Xerox Ventura Publisher.
Безусловно, Ventura — выдающаяся система, однако качество модуля переносов, включенного в русифицированную версию, было удручающе низким. Сегодня из массы ошибок помню лишь «пол-иция». Но и этого примера достаточно, чтобы составить представление об общем уровне разработки. С той поры и до дня сегодняшнего тема переносов остается актуальнейшей для всех издательских систем без исключения. Предлагались разные решения: более удачные, менее. Но никогда не было решения, которое позволило бы забыть о переносах, чтобы стало как в здоровом теле — не чувствуешь же, например, сердце, когда оно в порядке.
Самым грустным оказалось то, что многие перспективнейшие разработки, которые в других условиях можно было бы довести до совершенства и закрыть проблему переносов навсегда, не пережили нашествия «неплательщиков». Счет тех, кто покупал системы расстановки переносов, шел на единицы. Кроме издательства ЭКСМО я сейчас и вспомнить никого не могу. Так и ушли в историю и UniSpell, и Russian Language Extender. В общем, к моменту появления Corel Ventura 8 уже не осталось никого, кто хотел бы сделать систему переносов для нее. Могли еще многие, но не хотел уже никто.
Пришлось самому приниматься за работу. Конечно, я никак не предполагал, что работа растянется у меня на всю оставшуюся жизнь. Хотелось-то всего-навсего получить возможность готовить к печати книги в новой программе. Создание системы расстановки переносов было для меня задачей вспомогательной. И отводил я на ее решение максимум полгода. Однако не учел того, что работу начинаю в «голом поле» и полной изоляции. Главной проблемой оказались словари. Сегодня их можно легко найти в Сети. Или, например, загрузить с моего сайта — причем как сами словари, так и образцы того, как должны выглядеть в этом словаре переносы. Тогда же пришлось все создавать с нуля.
Но, несмотря на все сложности, через четыре года система была в основном готова…
Применяться на практике новая разработка стала c самых первых дней: в 90-е годы я тесно сотрудничал с издательством ЭКСМО, где работали очень сильные корректоры. С каждой подписанной в печать книгой число ошибок в программе неуклонно сокращалось. И наступил момент, когда корректоры перестали находить ошибки в изданиях, подготовленных с помощью моей программы. Это была победа. Но одновременно возникли и новые трудности. С этого момента в деле тестирования корректоры мне уже не могли помочь. Дальнейшее развитие алгоритма требовало нового подхода к тестированию в случае редко встречающихся словоформ. Постепенно со всеми проблемами удалось справиться. Теперь все это уже в прошлом.
Сегодня как пользователя разработка меня устраивает абсолютно. То, что требуется от системы расстановки переносов, она делает и делает очень и очень хорошо. Но как разработчику мне бы хотелось добавить и то, и другое, и третье. Хотя, по большому счету, это уже украшательство. Здесь главное — вовремя остановиться, не перегрузить систему массой ненужных функций.
Есть Правила переносов в редакции 1956 года, а есть жизнь языка, какие-то тенденции в обществе упростить правила русского языка. Это как-то влияет на принимаемые решения в совершенствовании алгоритма?
Говоря о тенденциях (я берусь судить лишь о том, что относится к расстановке переносов), я бы отметил существование двух встречных потоков. Один из их нашел свое выражение в Своде правил русского правописания. Орфография. Пунктуация, подготовленном в 2000 году в секторе орфографии и орфоэпии Института русского языка им. В. В. Виноградова РАH. Если коротко, в Своде предлагалось предельно упростить правила: сохранив 4 строгих запрета, во всех прочих случаях предоставить пишущему право использовать любой вариант переноса.
Встречный поток — поток, идущий снизу, направлен даже не на восстановление или соблюдение Правил 1956 г. Явочным порядком вводятся правила, которые не идут ни в какое сравнение по количеству ограничений, налагаемых правилами действующими. Этот «крестовый» поход начат отнюдь не корректорами или редакторами. Наиболее часто инициатива исходит от верстальщиков. Их немного, но они есть. Таких людей на своем сайте я и именую гурманами… (В этом же русле находятся движение за восстановление использования буквы «ё», употребление кавычек-лапок в соответствии с русской печатной традицией, правильное использование тире, минуса и дефиса...)
Следует отметить, что крайние взгляды на способы переносов присутствовали всегда. Например, кто-то выдвигал требования не разделять «бл», «вл», «мл», «пл», «фл», «жд». Другие полагали, что, например, суффикс «ющ» нельзя разбивать переносом. Есть и такие, кто уверен, что нельзя разбивать сочетания «дж», «кс». А, например, М. В. Шульмейстер считал, что существующие в некоторых типографиях списки сочетаний согласных, не подлежащих разделению при переносах, ничем не обоснованы.
В общем, сколько людей — столько и мнений. Я здесь не являюсь исключением. С тем, что же именно должно быть закреплено в алгоритме, с тем, какой мне видится идеальная книга с точки зрения расстановки переносов, я определился давно, когда только приступал к работе над программой. Так что, сегодня совершенствование алгоритма происходит лишь в той части, что касается реализации.
Как известно, правила в языке закрепляют определенные нормы определенных групп определенного времени. Они не конструируются и не выдумываются. Соответственно и разработка, и развитие алгоритма проходят в диалоге и сотрудничестве со всеми заинтересованными сторонами. Вот только к этим заинтересованным сторонам я отношу и тех, кто жил до нас. С той лишь разницей, за них говорят книги, которые они оставили после себя. Но их видением того, как быть должно, я руководствуюсь в первую очередь. Конечно, и тридцать и пятьдесят лет назад взгляды людей могли расходиться. И приходилось выбирать. Но выбор этот был между хорошим и лучшим…
В целом же развитие алгоритма определяется только моим внутренним стремлением создать некий идеальный инструмент. Но этот инструмент, безусловно, отражает определенный взгляд на вопрос расстановки переносов.
Просматривая издания середины прошлого века и нынешние, можно найти слова, переносящиеся по-разному, и у разных корректоров будут свои аргументы в пользу каждого из вариантов. Например, "из-учить" и "изу-чить", оба варианта можно встретить в книгах. Какое решение принимает Ваш алгоритм в таких сложных случаях?
Если ответить коротко, то приоритет принадлежит морфологическому принципу. Применительно к данному случаю это означает, что выбирается вариант «из-учить». Опять же, если говорить о приведенном примере, я бы не рискнул утверждать, что оба варианта можно встретить в книгах. Точнее, вариант «из-учить» мне не встречался ни разу. Но это один из тех немногих случаев, когда при принятии решения о положении переноса традиция была подчинена Правилам и требованию унификации. На мой взгляд, вариант переноса не должен зависеть от вида приставки. То есть, для меня более приемлемы варианты: «из-учить», «об-учить», «вы-учить», «до-учить» «за-учить», «на-учить», «пере-учить», «про-учить».
Вообще всегда, когда у меня возникала проблема с выбором варианта постановки переноса, я обращался к изданиям, которым доверяю. Просмотрев огромное количество книг, выпущенных в период с начала 50-х и до конца 70-х годов — я сознательно ограничил круг изданий книгами, подготовленными в докомпьютерную эру, — остановился на книгах, выпускавшихся издательствами «Детгиз», «Мысль», «Искусство». Таким образом я заочно консультировался и консультируюсь с огромным числом корректоров и редакторов. Периодически обращаюсь к БСЭ. В ней я, например, нашел подтверждение правильности вариантов «Ленин-абад», «Сталин-абад», которые и зафиксированы в алгортиме начиная с версии 1.09. Если возникала необходимость в расстановке переносов в терминах математических, химических, медицинских, я обращался к изданиям из этих предметных областей. Традиция, закрепленная в них, переносилась в алгоритм.
Возвращаясь к дилемме «из-учить—изу-чить», хочу сказать, что, предлагая сегодня вариант «из-учить», я абсолютно не настаиваю на нем, а лишь предлагаю пользователям — и читателям, и издателям — высказаться по данной проблеме. Если большинство предпочтет классическое решение, оно и будет окончательно закреплено в алгоритме.
Для многих ведение реестра покупателей на Вашем сайте, загрузка и обновление по Сети показались необычными. В чем, на Ваш взгляд, достоинство такого метода доступа легальных пользователей к Вашей разработке?
Достоинство у выбранного способа регистрации (защитой такую систему можно назвать с очень большой натяжкой), пожалуй, одно: удается избежать привязки программы к «железу». Но, в принципе, любые системы защиты, регистрации создают для пользователя неудобство. Функционирует это следующим образом.
При каждом запуске Adobe InDesign CS3 плагин сообщает на сервер, что приступает к работе. Никакая другая копия, запущенная после этого от пользователя с тем же именем, расставлять переносы не будет. То есть, для каждого кода доступа на нескольких машинах, подключенных Интернет, в данный момент времени активной может быть только одна копия. Таким образом, фактически реализуется привязка программы не к «железу», а ко времени. Мне, поскольку я сам много готовлю книг к печати и все решения примеряю на себя, прежде чем предлагать их другим, такой режим представляется более комфортным. Приобретя всего одну копию, можно работать с ней на любом компьютере. Не надо волноваться по поводу апгрейда, переустановки ОС и т. п. Опять же при привязке к «железу» требуется приобретать столько копий программы на скольких компьютерах вы планируете ее использовать.
Реализация вышеизложенных соображений привела к тому, что, если приобретен один модуль, при переходе с компьютера на компьютер необходимо заново регистрировать свою копию плагина на сервере (запуская каждый раз setup_cs3.exe в случае Adobe InDesign CS3). Уходит на это секунд 40-45.
В чем суть обновлений программы? Если Вы ее писали больше 10 лет, то, что в ней вдруг появилось такого, что она обновляется еженедельно?
В действительности все эти годы программа обновляется ежедневно. Но поскольку сегодня поддерживается несколько версий, необходимо перед выпуском коммерческой версии провести полное тестирование всех версий. На это уходит два полных дня — суббота и воскресенье. Причин же, по которым обновления выходят столь часто, две.
Во-первых, я не выношу ошибок… Мне легче их исправить, чем уговорить себя подождать, когда будут найдены и другие неточности, чтобы устранить все за один раз. Ведь если можно исправить немедленно, почему этого не сделать?
Во-вторых, когда четыре года назад я создавал сайт, то высказал пожелание: «В конце концов, модуль переносов не операционная система, и, если не каждый день, то хотя бы раз в неделю, можно было бы получать обновление». Теперь вот стараюсь поставить дело так, как когда-то представлялось мне правильным.
Как организовать работу с программой, если верстка отдается на сторону?
Необходимо установить аналогичный модуль на второй машине.
Обновления могут стать причиной того, что в работе, сделанной год назад, изменится расстановка переносов, если будет активен последний модуль, а не тот, что использовался тогда?
Здесь надо правильно понимать: обновление — другой продукт. Со всеми вытекающими отсюда последствиями. Конечно, предыдущая и новая версия достаточно близки, и процент изменений не будет велик, но все-таки это разные продукты. Обычно удается очень быстро привести публикацию к прежнему виду. Но лучше всего сохранять предыдущие версии плагина.
На сайте я уже обращал внимание пользователей на то, что новая версия устанавливается поверх старой и что перед установкой новой версии старую следует сохранить. Можно, например, перед обновлением переименовать файл bah.pln в bah.107, bah.108 и т. п., а хранить в той же папке, где располагается работающая версия. Это очень удобно: не надо искать или запоминать, где хранится архив... Восстановить предыдущую версию столь же легко: достаточно переименовать файл, допустим из bah.105, в bah.pln. Но лично я предпочитаю переверстать работу под новый модуль.
Как предполагается развивать программу дальше?
Все будет зависеть от того, как пойдет дело. Если придется сочетать разработку новых версий с поддержкой текущих и подготовкой к печати книг, боюсь, много сделать не удастся. Если же получится полностью переключаться на разработку, тогда можно будет говорить и о планах. Наиболее вероятное направление дальнейшего движения — перенос разработки на другие платформы, реализация под другие программы. От программы, выполняющий только одну функцию, и требовать, мне кажется, следует только одно — она должна справляться с решаемой задачей идеально. Если этого не происходит, смысла в такой разработке нет... Поэтому качеству переносов будет уделяться основное внимание.
Но даже если все пойдет не так, как хочется, и проект придется закрыть, я отнесусь к этому спокойно. То, что я хотел сделать, я уже сделал: BAH установил новый стандарт качества для систем расстановки переносов. Теперь всякая новая разработка будет просто обязана превосходить BAH. В любом случае мы никогда уже не встретим в книгах столько ошибок в переносах.
Менталитет общества таков, что чужой труд фактически не ценится. Пока правят бал халявщики, лучше украсть или взломать, чем купить. Не боитесь, что найдется умник, которому все равно что хакнуть?
Теперь уже не боюсь. Но еще год назад я не исключал такой возможности. Это даже привело к тому, что выход плагинов задержался на несколько месяцев: решено было снабдить разработку системой защиты от несанкционированного распространения. Написал по всем правилам… и пришел в ужас от нелепости и несоразмерности получившегося. Меры по охране, которые больше подошли бы для защиты государственной границы, применялись для обеспечения безопасности садового домика. Пришлось все срочно переделывать. Но защита была интегрирована в разработку столь глубоко, что следы ее пребывания можно видеть еще и сегодня. В коммерческой версии осталось лишь небольшое декоративное заграждение.
В действительности все оказалось гораздо проще. Правда, выяснилось это уже после начала продаж. Разработку ведь нельзя приобрести анонимно. Обязательно с потенциальным покупателем что-то обуждаем, уточняем… И оказалось, что между всеми купившими разработку очень много общего. Все это люди успешные, состоявшиеся, занимающиеся серьезными проектами. Почти всем около сорока или больше. Когда же я слышу: «умник, которому все равно что хакнуть» — в сознании рисуется совершенно иной образ. Я не могу представить, что человек, понимающий, что, например слова «суженный» и «суженый», следует переносить по-разному, будет что-то взламывать… Общий высокий уровень развития, культуры задает и стиль поведения, определяет представления о добре и зле и т. д.
Если же взглянуть на это с точки зрения рациональной, окажется, что рубить сук, на котором сидишь, можно только по недомыслию. Не думаю, что кто-либо после BAH захочет вернуться к Proximity. К хорошему привыкаешь быстро. А реальных альтернатив пока не видно. Это во-первых.
Во-вторых, на мой взгляд, ситуация сегодня уже не та, что в 90-е годы. Тогда все-таки цены на программы и доходы реальных пользователей были несоизмеримы. При заработке в 100 долларов купить программу за 50 крайне сложно. Когда же зарабатываешь 1000 или 2000, это проходит легко и незаметно. Гораздо проще купить и жить спокойно.
К тому же это своего рода вложение в собственный завтрашний день. Когда для очередной версии, допустим того же InDesign, понадобится качественная система переносов, людям будет куда обратиться… И отправятся они не на форумы с вопросом «Где взять переносы», а конкретному разработчику… А если вы уверены, что у вас все необходимое будет, и причем самого высокого качества, то и свою деятельность можно организовать и планировать совсем иначе.
Из просмотра форумов можно понять, что пользователи обходят недостатки других модулей переносов добавлением собственных словарей. А как надо организовать работу со словарями при использовании модуля ВАН?
Работа со словарями при использовании BAH ничем не отличается от работы со словарями, допустим, в случае использования Proximity. Здесь нет проблем. Но, на мой взгляд, и смысла нет. Использование словарей — это вынужденная мера, отражение нежелания разработчиков тратить силы на тестирование своей продукции. Сделали что-то — и скорее в продажу... Какое уж тут тестирование. Забота о качестве просто перекладывается на плечи пользователей. И получается: каждый пользователь вынужден создавать свой индивидуальный словарь, который практически не отличается от тех, что делают другие, и единственное назначение которых — исправить ошибки разработчиков.
Для меня такой подход абсолютно неприемлем. Все должно быть с точностью до наоборот: надо не словари создавать, а исправлять алгоритмы. Иначе конца ошибкам не будет. Словарь необходим, если невозможно от разработчиков получить поддержку. На мой взгляд, это безобразие, что модуль Proximity из CS2 перекочевал в CS3 без единого изменения. Вот уж где работы непочатый край. Здесь без словаря пропадешь.
И только в одном случае применение словаря оправдано. Когда работать приходится в узкой предметной области. Например, при подготовке изданий по органической химии. Перекладывать обработку химической терминологии на алгоритмы, рассчитанные на работу со словарями общей лексики, не самое лучшее решение. Несомненно, подход к решению данной задачи должен быть иным.
Игорь Владимирович, спасибо за подробные ответы. Будем надеяться, что это не последний разговор на страницах журнала о проблемах грамотных переносов.