| Предыдущий раздел |
Вернемся на землю. Введение в Unicode полной поддержки хотя бы позднего извода -- дело будущего. Каким образом сегодня располагать в шрифте или шрифтах большое количество лигатур, необходимых для качественного издания? Вместе с самим способом будут рассматриваться простота смены гарнитуры и возможность задания внутришрифтового кернинга. Изменение межсимвольного расстояния (трекинг, разрядка, выключка межбуквенными промежутками) зависят не от способа расположения лигатур, а от того, является ли КШС полнолигатурной или содержит накладные надстрочники.
16-битные шрифты. Расположение вне кодовых страниц Windows
Официального места для церковно-славянских лигатур в Unicode не предусмотрено, поэтому самым корректным способом было бы расположить все необходимое вне занятых диапазонов. Тем более, что в Unicode предусмотрена так называемая Private Use-зона, в которой, по идее, можно располагать любые "неофициальные" символы.
К сожалению, попытки решить этот вопрос корректно чаще всего оканчиваются неудачей, ибо зачастую не находят для себя поддержки со стороны ОС и софта.
Прежде всего, размещение символов вне позиций, принадлежащих хотя бы одной из кодовых страниц Windows, автоматически делает их недоступными для 8-битных приложений. Со всеми вытекающими.
Далее, даже 16-битные приложения очень часто отказываются корректно работать с некоторыми зонами Юникода. Например, с приватной. MS Word 97 и 2000, например, отказываются отрисовывать символы из приватного диапазона. Имеются средства ввода в текст таких символов; анализ записанных RTF-файлов показывает, что Word хранит эти символы вполне корректно; далее, мы делаем шрифт, в котором нужные символы на нужных позициях имеются, и проверяем его в других 16-битных приложениях -- символы работают; -- однако, Word упорно показывает квадратики на месте именно символов из приватной зоны. Обидно, однако.
InDesign 1.5 "приватные" символы показывает корректно, но между ними не работает кернинг, хотя в шрифте он имеется.
Аналогичные препятствия поджидают дизайнера при попытке разместить лигатуры уже не совсем корректно, в официально занятых зонах Unicode. Например, помещение символов в CJK Unified Ideographs (4E00-9FAF) приносит неожиданные результаты. IE 5 (возможно, с доустановленной поддержкой CJK-группы) показывает эти символы именно как иероглифы, игнорируя реально находящиеся в шрифте глифы. Word и InDesign их также показывают, но кернинг опять не работает (вертикальное письмо, как-никак).
Приведенные примеры показывают, что оптимальная для "пиратского" занятия зона Unicode, возможно, и существует, но нужны подробнейшие исследования софта, а именно их реакция на символы нужной зоны. "Непиратский", корректный способ размещения приватных лигатур на сегодняшний день, похоже, отсутствует.
16-битные шрифты. Расположение на позициях кодовых страниц Windows
Очевидно, наиболее корректно с точки зрения общих норм европейского письма (направление письма, кернинг и подобное) в Windows будут восприниматься символы, принадлежащие европейским кодовым страницам Windows. Причем желательно тем, что поддерживались и в самых ранних версиях этой ОС: 1252, 1251, 1253. Метод, безусловно, нельзя назвать корректным с точки зрения официальных стандартов, но что делать?
Посчитаем. Кодовые страницы 1251 (Cyrillic), 1252 (Latin 1) и 1253 (Greek), с учетом пересечений и включая все знаки препинания и пробелы, дают нам 386 позиций или что-то около того (я мог ошибиться). Если добавить сюда 1250 (Eastern European), 1254 (Turkish) и 1257 (Baltic), число увеличится до 465 (слишком много символов уже продублировано в других страницах). Хочется взять еще 1255 (Hebrew) и 1256 (Arabic), но это уже правостороннее письмо, и мы рискуем нарваться на проблемы.
Итак, 380-460 позиций. Вполне достаточно, чтобы разместить весь полнолигатурный комплект для новоцерковно-славянского письма. Возможно, что-то еще останется и для древних изводов.
Рассмотрим повнимательнее различные аспекты этого метода.
Доступность 8-битным приложениям. Мы использовали юникод-индексы лишь стандартных кодовых страниц, следовательно, если только 8-битное приложение умеет менять кодовую страницу текста внутри самого текста, ему будут вполне доступны все символы шрифта. Если приложение не умеет менять кодовую страницу, но умеет менять шрифт внутри текста, можно воспользоваться сечениями, прописанными в win.ini или реестре. Наконец, если приложение не умеет менять шрифт внутри текста (а умеет, скажем, задавать единый шрифт для всего текста), ему, очевидно, данный метод не подходит.
Здесь необходимо сделать одно предостережение. В секции FontSubsistuties реестра или win.ini очень часто прописывают подстановки следующего вида: FontName,0=FontName,204. Это делается с целью избежать видимых проблем со шрифтами старого формата. Так вот, для шрифтов, построенных по рассматриваемому методу, подобные подстановки противопоказаны, ибо они делают недоступной часть символов, расположенных на позициях 1252.
Способность простой смены гарнитуры. Предположим, у нас имеется два шрифта, построенных по единому рассматриваемому сейчас методу и в одной кодировке. Можем ли мы, набрав текст одним шрифтом, далее выделить некоторую его часть и просто поменять шрифт фрагмента? Разумеется, увидев при этом вполне корректный текст без проблем с надстрочниками, но набранный уже другой гарнитурой?
В 16-битных приложениях однозначно -- да. В 8-битных результат действия зависит от того, как мы заставили видеть приложение разные кодовые страницы. Если в приложении возможно указание кодовых страниц напрямую, простоя смена шрифта возможна. Если же мы пользовались сечениями, простая смена шрифта испортит текст. Здесь необходима более тонкая работа по замене всех шрифтов вида OldFont Cyr, OldFont Greek на NewFont Cyr, NewFont Greek.
Кернинг. В 8-битных приложениях "с сечениями" невозможен, ибо для подобных программ Font Cyr и Font Greek -- совершенно разные шрифты. В 8-битных приложениях "со сменой страниц" кернинг возможен, если приложение умеет "склеивать" участки, набранные в разных страницах. К сожалению, практика показывает, что теоретически существующая возможность никогда не поддерживается на практике. Таким образом, полный ответ для 8-битных приложений -- кернинг между символами из разных страниц, как правило, не поддерживается. Исправить это положение отчасти можно, сгруппировав в разных кодовых страницах лигатуры, не требующие кернинга между собой.
Кернинг в 16-битных приложениях, по идее, работать должен. Но, опять же, на практике встречаются мелкие препятствия, связанные обычно с тем, что 16-битные приложения подчас пытаются сохранять совместимость со своими старыми 8-битными аналогами, либо не умеют совершенно безошибочно склеивать различные куски текста с разными атрибутами. Например, в Word 97/ 2000 кернинг иногда не работает даже между русскими и латинскими буквами. В данном случае положение исправляется установкой по всему тексту единого языка "русский".
Метод основан на том, что все множество необходимых знаков КШС располагается в нескольких шрифтах, занимая в каждом шрифте лишь пределы какой-то одной кодовой страницы. То есть, в каждом шрифте располагается не более 224 символов, а большее, чем эта цифра, количество лигатур помещается в КШС за счет использования нескольких сгруппированных в эту КШС шрифтов.
Вот пример такого метода. В первом шрифте мы располагаем все основные символы и знаки препинания -- без надстрочников вообще. Во втором -- те же символы, но над всеми нарисованы прямые ударения. В третьем -- обратные ударения, в десятом -- слово-титла, и т.д. Даем этим шрифтам какие-то показательные имена, вроме FontName Normal, FontName Acute, FontName Grave, и т.д. Теперь, чтобы поставить над буквой "а" прямое ударение, достаточно просто выделить эту букву и сменить шрифт с FontName Normal на FontName Acute.
Доступность такого "набора" шрифтов (корректнее здесь говорить о КШС) из 8-битных приложений очевидна, ведь мы занимаем в каждом шрифте пределы лишь одной кодовой страницы. Единственное требование к приложению -- способность менять шрифт внутри текста. Для приложений с возможностью выбора лишь одного шрифта для всего текста сразу этот метод неприменим.
Простая смена гарнитуры здесь, очевидно, невозможна вне зависимости от кодировочной разрядности приложения. Чтобы сменить гарнитуру, мы должны будем последовательно менять OldFont Normal, OldFont Acute, OldFont Grave на NewFont Normal, NewFont Acute, NewFont Grave.
Кернинг между буквами разных шрифтов работать также не будет.
Единственное достоинство такого метода -- он не вызывает практически никаких проблем у 8-битных приложений, и, главное, количество размещаемых лигатур в этом методе не ограничивается ничем. Посему метод может быть перспективным для реализации древних изводов.
У метода имеется также и существенный недостаток для дизайнеров: чудовищная сложность во внесении каких-либо изменений в контуры букв или метрики. Чтобы исправить одну-единственную букву, дизайнер должен последовательно обойти все шрифты коллекции, то есть, загрузить, исправить, записать и откомпилировать заново каждый шрифт. По личному опыту знаю, что это довольно тяжело.
Использование начертаний внутри шрифтового семейства
Довольно удачная модификация мультишрифтового метода. Основано на возможности задавать в операционной системе отдельные шрифтовые файлы для начертаний Normal, Bold, Italic, Bold Italic. Безусловно, начертаний существует больше, однако в Windows (другие ОС мы в этой статье не рассматриваем) для TrueType можно задавать отдельными шрифтами только эти четыре. Остальные она при необходимости генерирует сама.
Итак, если количество лигатур у нас таково, что может поместиться в двух или четырех 8-битных страницах, можно воспользоваться методом начертаний. В церковно-славянском письме не практикуются полужирные и курсивные начертания, вместо них используются печать киноварью, разрядка и, изредка, капитализация. Если метод реализации надстрочников у нас -- полнолигатурный, мы можем смело изменять межсимвольное расстояние разряживаемых участков, а, следовательно, нам не нужно делать отдельное "разряженное" начертание отдельным шрифтом. Иногда, правда, отдельным начертанием на Bold делают Outline, предназначая его для отображения киноварных участков на черно-белом принтере (удобно закрашивать фломастером).
В любом случае, мы имеем хотя бы два, а в лучшем случае -- четыре свободных начертания для размещения в них лигатур.
Не могу не рассмотреть здесь же очень удачный частный случай рассматриваемого метода: на двух начертаниях с разделением по регистру букв.
Напомню, для новоцерковно-славянского письма нам необходимо порядка сотни основных символов и их вариантов, 277 лигатур и десяток знаков препинания. Плюс арабские цифры на всякий случай. Итого около 400 позиций без накладных надстрочников. Цифра, удобная для размещения без тесноты на двух 8-битных страницах. Метод с разделением по регистру букв располагает их в двух начертаниях одного шрифтового семейства (обычно Normal и Bold), причем в Normal помещаются все буквы и лигатуры малого регистров, а в другое -- на те же позиции их заглавные пары.
Таким образом, мы спокойно набираем текст в малом регистре, а для того, чтобы получить заглавные буквы, просто делаем их полужирными.
Очевидно, чтобы метод работал, от текстового процессора необходимо умение менять начертание внутри текста. Ну и, конечно же, способность распознавать установленные в системе начертания, выполненные в виде отдельных шрифтов, а не генерировать их в любом случае самому. Впрочем, даже если обе эти возможности в текстовом процессоре отсутствуют, для способа с разделением по регистрам остается возможность набора текста только в малом регистре.
Доступность 8-битным приложениям. Очевидно, проблем здесь не будет, ведь в каждом начертании мы занимали только одну кодовую страницу.
Простая смена шрифтов. Очевидно, она будет работать без особых проблем, ведь смена шрифта (точнее, шрифтового семейства) и смена начертания в текстовых процессорах -- это, как правило, независимые друг от друга операции.
Кернинг. Кернинг будет работать между символами одного начертания и не будет -- между разными. Для способа разделения по регистрам это означает, что задавать кернинг между заглавными и строчными буквами нельзя. Для многих это может оказаться существенной потерей, но в целом данный метод я считаю очень удачным.
| Предыдущий раздел |