OpenType-формат — шесть лет спустя
Дмитрий Юнов 
Лигатуры в современной кириллице
Исторические варианты алфавита
«Шрифтовые войны» и борьба пользователей за поддержку их национального языка и его типографики в стандартных компьютерных приложениях
Некоторые уточнения
Прежде всего договоримся о терминологии, используемой в этой статье. Под словом «документ» мы понимаем всю совокупность любых компьютерных ресурсов, использующих текстовое представление информации, предназначенное для визуального чтения, интерпретации пользователем и/или последующего процесса печати: word-processing-документы, графические материалы в компьютерных форматах с любыми фрагментами текста, классические DTP-публикации, Web-материалы, отчеты баз данных, help- и гипертекст-системы, текстовые ресурсы, используемые в приложениях для создания элементов меню и диалоговых окон взаимодействия программы с пользователем. Во всех этих и ряде других случаев визуализация через вывод на экран или печатающее устройство осуществляется теми или иными шрифтами в соответствии с определенными правилами национальной поддержки данного языка.
Термин «поддержка языковой группы» означает поддержку операционной системой (включая шрифты) и/или приложением всей или большей части совокупности исторических и текущих правил письменности данного языка, нации или этно-культурного региона, его национальных стандартов в отношении календаря, систем и форм счисления и национальной валюты, формата даты, используемых систем письма, алфавитов, порядка сортировки текста на национальном языке, его национальной типографики. В отличие от принятого в компьютерной области термина «локаль» (locale) и NLS (national language support) мы вкладываем в данное понятие бо'льшее содержание.
Обсуждение различий и границ между этими понятиями в тему данной статьи не входит.
Некоторые тезисы статьи содержат ряд необходимых и неизбежных при описании столь сложного материала упрощений, не влияющих на ход изложения и выводы. Автор полностью отдает себе отчет в качестве и степени этих упрощений и надеется избежать возможных упреков за этот шаг. Автор также с благодарностью примет все конструктивные замечания и уточнения.
 |
|
Введение
Разговор о национальных шрифтах и новых шрифтовых технологиях, реальный доступ к которым мы получили с выходом Adobe InDesign, не имеет смысла без понимания сложившейся на сегодня ситуации в области поддержки национальных компьютерных стандартов и технологий типографики, используемых при подготовке документов и публикаций на основных платформах — Windows и Macintosh.
|
|
Немного истории
В течение 1996 года, после совместного публичного заявления Adobe и Microsoft о переходе на новый единый открытый формат шрифтов OpenType с расширенной типографикой и огромными возможностями поддержки национальных стандартов текстовых сред, практически все ведущие обозреватели DTP- и pre-press- журналов торжественно объявили об окончании так называемой шрифтовой войны, длившейся более 6 лет.
Термин этот отражает ситуацию, возникшую в конце 80-х — начале 90-х годов, из-за закрытости в то время ряда технологий PostScript, отказа MS от возможного лицензирования у Adobe шрифтовой технологий Type 1, а в дальнейшем — более продвинутой технологии визуализации Display PostScript. Данный отказ был закреплен фактом появления в 1991 году первой действительно массовой операционной системы Windows 3.1 с собственной графической подсистемой, имеющей встроенную поддержку шрифтов формата TrueType, лицензированного MS у Apple.
Необходимо упомянуть сложившийся к началу 90-х годов безусловный промышленный стандарт, основанный на использовании PostScript-технологий и шрифтов Type 1 фирмы Adobe в издательском деле, pre-press-сервисе, DTP, системах, требующих высокоточной графической визуализации (WYSIWYG), печати для Macintosh-, SGI- и UNIX-платформ. Развивая этот успех PostScript, в конце 80-х Adobe предложила единую кросс-платформенную систему шрифтовой поддержки, высококачественной графической визуализации и печати, известную как Display PostScript.
Данная технология была успешно применена на high-end UNIX-workstation, использующих, например, такие операционные системы, как NeXTStep (NeXT; 1993) и Solaris (Sun Microsystem; с 1994-го по настоящее время). В то же время и MS, и Apple отказались от лицензирования Display PostScript, аргументируя это повышением стоимости их собственных операционных систем для конечных пользователей, что было связано с необходимостью дополнительных лицензионных отчислений Adobe с каждой проданной или установленной копии программы или иного устройства, использующего Adobe PostScript (например, драйвера PS и FirmWare-принтера, фотонаборного автомата). Таким образом, de-facto произошло разделение реальных форматов шрифтов, принципов построения и поддержки национального шрифта в операционной системе и приложении на следующие направления: Adobe Type 1 (в версии для Macintosh и в версии для MS Windows), Apple TrueType, MS TrueType.
Возникшая проблема тройственности национальных шрифтовых форматов в сфере DTP и документ-менеджмента начала резко усугубляться после очевидных расхождений в понимании каждой фирмой (Apple, Adobe и MS) принципов и уровня поддержки национальных стандартов для той или иной платформы и операционной системы.
|
|
Microsoft
После сравнительно недолгой ориентации MS на поддержку языковых групп посредством только кодовых страниц, где каждой языковой группе была выделена своя локаль, в Windows NT (1993) был выбран, как оказалось, правильный путь на поддержку стандарта Unicode (http://www.unicode.org/). Стандарт этот интересен тем, что в нем были классифицированы все существующие и большинство «мертвых» языков мира, а также их письменные системы, типографские и специальные знаки. На основе этой классификации была построена линейная классификационная таблица соответствий любого знака-буквы-графемы-символа специальному уникальному Unicode-индексу. Таким образом, операционная система (или приложение), использующая как основу для работы с текстом, документами и именами стандарт Unicode, вместо ориентации на отдельные национальные кодовые страницы и локали может работать с любым языком или даже их множеством, а не только с тем, что был предусмотрен при ее создании. Для поддержки сложных письменных систем и их типографики MS дополнительно расширил TrueType-формат и графическое ядро Windows-системы, назвав такое расширение формата TrueType Open.
Очень раннее внедрение поддержки стандарта Unicode (начиная с его версии 1.1), что является огромной и безусловной заслугой MS, решило многие проблемы мирного сосуществования национальных текстов в одном документе, прозрачного использования национальных и многоязычных документов в различных приложениях и даже использования таких документов и публикаций на различных платформах без дополнительной конвертации национального текста. Хорошим примером является прямое (без конвертации) открытие практически любых многоязычных или национальных документов, созданных в MS Office 97, 2000, XP на Windows-платформе в Office 98, 2001, XP для Macintosh, и наоборот.
Возвращаясь к теме национальной шрифтовой поддержки, отметим, что именно в этом направлении — добавление Unicode-совместимости и поддержка более чем одного национального языка в одной копии шрифта — формат TrueType, как мы отмечали ранее, лицензированный у Apple, начиная с 1993 года (Windows NT 3.5), был модифицирован MS. В результате современный MS TrueType-шрифт из современной версии Windows содержит все необходимые символы для более чем одной кодовой страницы, и организован так, что доступ к ним возможен только через линейную Unicode-таблицу, представленную в шрифте (Unicode CMAP). Стандартно практически любой MS TrueType-шрифт содержит символы, покрывающие следующие кодовые страницы — CP1252 Western, CP1250 Eastern European, CP1251 Cyrillic, 1253 Greek, CP1254 Turkish, CP1257 Baltic, основные символы псевдографики; эта совокупность символов называется WGL4. В таком шрифте не содержится никакой информации о поддержке им той или иной отдельной кодовой страницы, а доступ приложения к той или иной отдельной национальной букве или символу, как отмечалось выше, осуществляется только через таблицу Unicode CMAP в заголовке шрифта.
|
|
Apple
Несколько иным путем развивался формат TrueType на платформе MacOS. Национальная поддержка в операционной системе была представлена через WorldScript I (WorldScript II предназначен для работы с японским, корейским и китайским языками, эта группа языков сокращенно обозначается CJK) расширения операционной системы, где основным национальным языковым группам соответствовал свой уникальный идентификатор — Apple Language Script ID. Для работы с той или иной Non-Roman-языковой группой — например с русским, греческим, грузинским, армянским языками и языками Балтии — было необходимо дополнительно приобрести и установить соответствующий Language Kit. Основным производителем пакетов Language Kit выступала сама Apple, однако для греческого, грузинского, армянского, монгольского, тибетского языков, тюркских языков бывших республик СССР, Центральной и Юго-Восточной Азии такие пакеты производились сторонними фирмами. К ним относятся, например, замечательные и во многом уникальные продукты Language Kit от Xenotype Tech — http://www.xenotypetech.com/ (автор Даниэл Кай (Daniel Kai)). Похожие решения дают продукты Михаэля Эмерсона (Michael Everson, http://www.egt.ie/earra_bog/apple/index.html) для грузинского, армянского и тюркских языков Центральной Азии.
|
|
Шрифты Macintosh
MacOS-шрифт очень долго оставался Unicode-несовместимым (формально — до MacOS 8.5, реально — до MacOS X), он был предназначен для поддержки языков только из своей языковой группы и ограничивался 256 знакоместами (с некоторыми исключениями для дополнительных типографских символов лигатур и ряда языковых групп, не рассматриваемых в данной статье).
Для работы на Macintosh-платформе с национальным текстом любое приложение должно было быть или полностью совместимым с WorldScript, или дружественным к нему. Под дружественностью имеется в виду пассивное невмешательство (прозрачность) приложения в действия операционной системы по реализации корректного использования национального языка.
Побочным эффектом такого подхода к национальной поддержке (аналогично MS национальным кодовым страницам) стали целые языковые/национальные группы, не имеющие или имеющие, но не способные использовать свой Language Script ID (Romanian, Central Asian former-USSR-регионы, народы России, использующие Extended Cyrillic или Extended Latin-системы письма, народы Закавказья, Mongolian, Icelandic) из-за отсутствия их поддержки в WorldScript или поддержки популярными приложениями самого WorldScript. Типичными примерами неподдерживающих WorldScript-приложений для языковых групп нашего региона может служить QuarkXPress, FreeHand, большинство Adobe-приложений, включая FrameMaker.
В таких проблемных ситуациях системные инженеры или опытные пользователи вынуждены использовать метод «обмана» приложения, принудительно изменяя в FOND-ресурсе национального шрифта его уникальный идентификационный номер. Поскольку каждому Apple Language Script ID (языковой группе) соответствует свой выделенный диапазон уникальных идентификационных номеров шрифтов, переключение такого номера шрифта, например, из Cyrillic-диапазона в MacRoman (Western Latin), как правило, решает проблемы с несовместимыми приложениями WorldScript. Таблицу диапазонов номеров и соотношение с ними языковых скриптов можно посмотреть, например, на http://www.egt.ie/earra_bog/apple/fontnums.html, однако проще воспользоваться специальными программами для решения подобных задач.
Хорошим примером утилиты, созданной для решения WorldScript I проблем национальных публикаций, служит Font ReIDer (1995, 1998, автор Oleg Kozlov). Иное решение предоставляют программы типа Dialect (MacCentre, Moscow) или UCS Language Kit (1996, 2001, автор Cyril Moorsin, FontLab DG), которые, не модифицируя сами национальные шрифты, имеют опциональную возможность при обращении к таким шрифтам WorldScript-несовместимых приложений «на лету» обманывать их, сообщая, что данные шрифты предназначены для работы и «по правилам» Roman Script1.
В качестве примеров полностью поддерживающих WorldScript I приложений можно привести текстовые процессоры WinText, (WinSoft, France, http://www.winsoft.fr/) и Nisus Writer (Nisus Software, Inc., http://www.nisus.com/), не получившие сколько-нибудь заметного распространения в данном регионе. Исключением, пожалуй, является более распространенный среди национальных пользователей — благодаря отличной системе Proof-reading tools и замечательной кросс-платформенной переносимости многоязычных документов WorldScript-compatible — текстовый процессор WordPerfect, прекративший, однако, свое существование на версии 3.5 и MacOS 8.
|
|
GX-AAT-ATSUI
Для дополнительной поддержки типографики, включая национальную типографику, и поддержки языковых групп со сложными системами письма в подготавливаемых на MacOS публикациях и документах компания Apple использовала несколько удачных последовательных расширений операционной системы и шрифтового формата Type 1/TrueType — GX, позднее — AAT (Apple Advansed Typography), и в настоящее время — ATSUI (Apple Type Services for Unicode Imaging). Подробнее об их истории и о возможностях вы можете узнать на сайте http://fonts.apple.com/ или в книге «Text subsystem» серии «Inside Macintosh», выпускаемой Apple. Отметим только, что GX-AAT-ATSUI нашли широкое применение для реализации поддержки на Macintosh сложных письменных систем основных языков Индии (Apple Indic Language Kit, Monotype GX fonts), арабского (система профессиональной газетной верстки Ready, Set, Go! от Diwan Software (http://www.diwan.com/), Apple Arabic Language Kit, Monotype GX fonts), фарси и урду (высококачественные локализованные DTP-приложения). Менее известна серьезная попытка фирмы Bitstream использовать возможности GX для расширения поддержки типографики языков на латинской основе (Bitstream GX Font Collection CD, 1995). Для использования GX и получения предсказуемого результата были необходимы GX-фонты и прямая поддержка GX в каждом драйвере принтера, специальная версия GX-compatible Adobe Type Manager, а в некоторых случаях и поддержка конкретных возможностей шрифтов в самом приложении. В настоящее время этот формат расширения возможностей шрифтов практически не используется, хотя его поддержка в той или иной мере еще встречалась в 8.х версии MacOS и некоторых программных продуктах DTP; его сменил новый, основанный на Unicode и свободный от ограниченной поддержки новых языковых групп при помощи WorldScript стандарт ATSUI (MacOS 8.6; 9.x; MacOS X).
|
|
Путь Adobe
Не менее сложный и драматичный путь развития прошла национальная шрифтовая поддержка в фирме Adobe. Основным фактором, очень сильно влияющим на развитие шрифтовых форматов PostScript, является то, что Adobe не выпускает собственной операционной системы уровня Windows или MacOS и, следовательно, не связана с маркетинговой необходимостью прямо поддерживать национальных пользователей, использующих нероманские письменные системы. Вторым (и последним) фактором, кардинально влияющим на данную ситуацию и по сей день, является исторически сложившаяся доминирующая поддержка данной фирмой исключительно западно-европейского и японского рынка компьютерных издательских систем, в основном для Macintosh-платформы. Эти же принципы действовали и десять лет назад, когда, вынужденная постоянно маневрировать между возникающими и исчезающими возможностями новых и старых версий Windows, MacOS, OS/2 и даже UNIX (Display PostScript), Adobe выпустила свой, вероятно, самый знаменитый, и уж точно самый успешный и массовый продукт — Adobe Type Manager — шрифтовой драйвер в комплекте с утилитой шрифтового менеджмента, предназначенный для интеграции и использования PostScript-шрифтов на экране и печати в операционных системах, не имеющих или отказавшихся от Display PostScript.
Указанные два фактора и являются, на наш взгляд, причиной очевидного краха шрифтового формата Adobe Type 1 в попытках обеспечить и преодолеть проблемы полноценной национальной поддержки и национальной типографики. Рассмотрим его более подробно.
|
|
Шрифт Type 1
Данный шрифтовой формат не содержит никакой информации о кодовых станицах или скриптах, не содержит он и Unicode-таблиц трансляции для однозначного вызова из DTP-приложения того или иного национального символа. Каждый графический символ в таком шрифте имеет свое уникальное внутри шрифта имя, эти имена перечислены в определенном порядке в единственной таблице в его начале, называемой таблицей encoding’а. Обращение к символу, его вызов через ATM основан на его знакоместе в таблице encoding’а.
Пытаясь облегчить работу DTP-приложения с PostScript-шрифтами, фирма Aldus в 1989-1990 годах для своих программ Pagemaker и FreeHand стала использовать для каждого шрифта специальный небольшой PFM-файл, где наряду с метрикой всех символов (ширины и кернинг) был зарезервирован один байт (по смещению 55h) под декларирование основной кодовой страницы, которую поддерживает данный шрифт. Файлы этого формата прижились,
и с тех пор неизменно сопровождают почти все комплекты шрифтов Type 1 на Windows-платформе. Их некоторым аналогом на Macintosh-платформе является Suitcase-шрифт, содержащий FOND-ресурс с похожими дополнительными шрифтовыми данными.
С появлением поддерживающих Unicode-приложений типа MS Office 97, MS Publisher 97, Netscape, MS Internet Explorer у национальных пользователей возникла проблема, связанная с невозможностью использовать там высококачественные национальные шрифты Adobe Type 1. Поскольку Unicode-таблица в шрифтах Type 1 отсутствует, единственным выходом для шрифтового драйвера ATM было, опираясь на встроенную в него таблицу соответствий уникальных имен национальных символов Unicode-индексу, построить такую таблицу для каждого шрифта. Эта возможность была впервые реализована в версии ATM 4.0 (1996) для Windows NT4, что восстановило работоспособность национальных шрифтов Type 1 для Unicode-приложений. В то же время в операционных системах Windows 95, 98, Me, уровень поддержки или использования в которых стандарта Unicode минимален или недостаточен для такого решения, ATM 4.0 не мог обеспечить нормальную работу национальных шрифтов Type 1, основанных на Unicode-приложениях. Отчасти проблема была решена самими пользователями: упомянутый выше файл PFM должен содержать правильно проставленный байт принадлежности шрифта Type 1 конкретной кодовой странице — например CP1251 Cyrillic, или CP1257 Baltic. Проблема, однако, заключалась в том, что ни одна из известных фирм-производителей национальных шрифтов Type 1 этому не следовала, а возможность такого решения не была документирована ни Adobe, ни MS, ни Aldus.
Подводя итог, перечислим три главных условия правильной работы национального шрифта Type 1 на Windows-платформе: все знаки, буквы и символы каждого шрифта должны иметь единственно правильное PostScript-имя (полный список этих имен и их соответствие Unicode-индексам и соответствующим национальным буквам и символам можно найти по адресу http://partners.adobe.com/asn/developer/type/unicodegn.html и http://partners.adobe.com/asn/developer/type/glyphlist.txt); шрифт должен иметь установку Custom encoding; таблица encoding’а для каждой конкретной кодовой страницы единственная и строго определенная, что обеспечивает уникальность знакоместа любого символа и его доступность по этому признаку в Non-Unicode-операционных системах типа Win95/98; PFM-файлы каждого шрифта должны иметь правильную установку поддерживаемой национальной кодовой страницы для 55h байта. Для пакетной обработки национальных шрифтов и выставления этого байта пользуются бесплатной утилитой T12MS (Type1-to-MS), доступной на различных shareware ftp.
Теперь вернемся к «шрифтовым войнам», с которых мы начали эту статью, «войнам», как нас уверяют, завершившимся с появлением формата OpenType в конце 1995 года. Так ли это?
К сожалению, это не так. И не последнюю роль здесь играет весьма сильное нежелание двух главных игроков — MS и Apple — договариваться между собой. Мы уже упоминали MS-расширение TrueType Open операционной системы Windows, которое полностью было включено в основу нового OpenType-формата. Однако оно абсолютно несовместимо с достаточно похожим по возможностям Apple ATSUI, являющимся ключевым компонентом новой MacOS X. На практике это означает, что возможности OpenType-шрифта с расширенной типографикой, например Palatino Linotype из комплекта Windows 2000, не будут работать на MacOS, и, наоборот, новый шрифт data-fork MacOS X ATSUI с лигатурами и дополнительными типографскими возможностями будет работать просто как обычный Unicode TrueType при его переносе под Windows.
|
|
Adobe CoolType
В этой ситуации понятно, почему Adobe была вынуждена пойти своим путем, фактически построив собственную операционную мини-систему, «государство в государстве», которая теперь встраивается в каждое Adobe-приложение независимо от того, на какой платформе — Mac, Windows или UNIX — это приложение используется. История ее появления такова. В 1996 году Adobe официально заявила об отказе от дальнейшей поддержки Display PostScript и занялась развитием внутреннего проекта, первоначально известного под кодовым названием Bravo. В итоге были реализованы первые приложения — Acrobat 3, Photoshop 5 и Illustrator 7, использующие единую модель кросс-платформенной среды для работы с PostScript-шрифтами, печатью, цветом и графической визуализацией. В настоящее время практически все Adobe-приложения, за исключением Pagemaker 6.5 и 7, FrameMaker 6 (как и его последующей версии 7), используют это уникальное кросс-платформенное решение. По имени главного модуля операционной мини-системы Adobe — модуля работы со шрифтами2, приложения, основанные на ней, называют «использующими CoolType engine». Эта патентованная технология пока не была лицензирована у Adobe ни одной фирмой, хотя известно о длительных, но неудачных переговорах Sun по ее возможному встраиванию в Java SDK и Sun Solaris.
В свете темы OpenType важно, что CoolType engine (а следовательно, и любое DTP-приложение, основанное на нем) самостоятельно, минуя операционную систему, поддерживает любую работу как со шрифтами TrueType (на основе кросс-лицензии MS и Apple), Type 1, так и с OpenType-шрифтами, обеспечивая не только их Unicode-поддержку, но и возможность использования расширенной типографики шрифтов. Таким приложением, например, является InDesign 1.5. Платой за такое решение являются проблемы полной или частичной несовместимости CoolType-приложений с национальной поддержкой, предоставляемой операционной системой (MacOS или Windows), под управлением которой оно работает. К преимуществам следует отнести полную прозрачность, совместимость документов и предсказуемость результатов независимо от того, на какой платформе был создан документ.
Рассмотрим подробнее такие дополнительные возможности национальной поддержки и типографики в шрифтовых форматах и приложениях.
Принцип всех подобных сложных систем (Apple GX, AAT, ATSUI, MS GDI «TrueType Open» и Adobe/MS OpenType, о которых речь пойдет далее) расширения возможностей операционной системы, шрифтов в области типографики и той или иной национальной системы письма практически одинаков. Графическое ядро операционной системы тесно взаимодействует с дополнительным GX, AAT, ATSUI, OpenType-таблицами, встроенными в шрифты, шрифтовыми драйверами, национальной клавиатурой, совместимым с данным расширением системы DTP-приложением и системой печати (обычно PostScript). При таком взаимодействии возможна прозрачная реализация полного управления необходимой для типографики подстановкой глифов или их групп, управление позицией каждого глифа в зависимости от ситуации.
|
|
Лигатуры
Каждый шрифт, помимо алфавитного набора букв национального языка, знаков пунктуации и типографского набора, обязательных символов, может содержать лигатуры и специальные варианты начертаний глифов — графически иные варианты начертания комбинации связанных групп букв и символов, капитель, цифры старого стиля. Широко известны лигатуры и диграфы, используемые в типографике языков Европы (например, sch, sz, cz, & (and), Œ, œ, β (ss), th, ff, ft, lj, Lj, nj, Nj, Dz, dz, fi, ffi, fl, ffl, ct, st, tt), где хорошим тоном считается использование лигатур при публикации. Реализуется это обычно путем автоматической замены операционной системой или программами верстки (в соответствии с национальными стандартами и типографскими традициями) той или иной часто встречающихся фонетики и ее буквосочетаний на стилистически и графически единое модифицированное их изображение для экрана и печати (без модификации самого текста !). Отсутствие какой-либо модификации исходного текста при использовании лигатур — весьма важный момент, обеспечивающий совместимоcть с другими программами и платформами, национальной клавиатурой, Clipboard, стандартом Unicode, системами сортировки текста, поиска и замены, расстановки переносов и проверки грамматики/орфографии, тезаурусом приложения.
Из-за более древней стилистической традиции восточного письма еще более широко лигатуры используются в системах, основанных на арабском, фарси, урду; индийских письменностях, основанных на деванагари/брахми, и, конечно, аналогичных письменностях Юго-Восточной Азии (кхмерское, классические бирманское, лао, тайское письмо).
|
|
Лигатуры в современной кириллице
Вопрос об использовании лигатур в современной письменной традиции языков, использующих
кириллицу (например, болгарском, русском, украинском, белорусском), далеко не
столь очевидно отрицателен, как могло бы показаться на первый взгляд. Исторические
лигатуры ю, ы, прекрасные образцы кириллической вязи, почти полностью состоящей
только из лигатур, церковно-славянская каллиграфическая и типографская традиция,
наконец, образцы каллиграфии современных нам шрифтовых художников, примеры декоративных
шрифтов, современных курсивов и скорописи свидетельствуют о наличии большого
количества фактических кириллических лигатур, триграфов и диграфов, тем не менее
абсолютно не реализованных в современной компьютерной типографике и известных
кириллических шрифтовых проектах. В качестве одного из примеров наличия лигатур
в кириллице приведем некоторую статистику графики частых буквосочленений кириллической
скорописи — лигатуры с б — 8 шт., с в — 6 шт., с в — 6 шт., с г — 2 шт., с д — 4
шт., с е — 5 шт., с л — 3 шт., с м — 3 шт., с о - 11 шт., с т — 3 шт., с у —
7 шт., и т.д.3 Относительно типографских
традиций других языков, упомянутых здесь, можно отметить, что, на наш взгляд,
очевидными кандидатами на белорусские лигатуры являются буквосочетания дз, дж.
Лигатуры в армянской типографике хорошо известны и даже реализованы в связке
MSOffice-W2K (пример — OpenType шрифт Sylfaen).
Было бы интересно и полезно получить комментарии кого-нибудь из ведущих шрифтовых
дизайнеров ParaType данной ситуации, тем более что современные программы верстки,
подобные InDesign, позволяют легко и качественно использовать собственные лигатуры
в тексте, основанном на любой письменной системе, включая кириллицу.
|
|
Исторические варианты алфавита
Другой весьма важной для нас возможностью сложных систем, основанных на ATSUI или OpenType, для языковых групп нашего региона является легкость реализации переключения или более сложной трансляции старых и нового алфавита-письма внутри одного ATSUI/OpenType-шрифта (поддержки глиф-подстановок) типа «исторический вариант» алфавита (национальной системы письма).
С помощью этой предусмотренной возможности OpenType в приложении легко реализовать переключение, в том числе и сложную трансляцию визуального/распечатываемого текста с одной версии алфавита на другую без модификации самого текста. Примером может служить сложившаяся на сегодня ситуация с азербайджанским (вернувшимся с небольшими модификациями на расширенный латинский алфавит, используемый в 1930-е годы), грузинским (сложная трансляция между асомтаврули, мхедрули и хуцрули —видами гражданского и церковного письма); армянским (лапидарное письмо, круглое письмо, скоропись), татарским (ситуация множественных исторически используемых алфавитов с трансляцией типа «один-в-много», и наоборот), болгарским, старо-славянским, узбекским (аналогично татарскому), туркменским, эстонским (где, например, в прошлом веке использовался готический алфавит с заменой буквы v на w) языками. OpenType-системы дают возможность полностью представить все варианты письменности любой национальности или региона в едином шрифте, обеспечивая прозрачное переключение между ними в обход ограничений кодовой страницы или локали.
|
|
Типографика внутри шрифта
Контекстуальные подстановки лигатурного типа и управление репозиционированием глифов (GSUB- и GPOS-таблицы OpenType-шрифтов) дают возможность легко реализовать многие обязательные типографские правила качественной верстки, например автоматические контекстуальные замены или добавления на экране/печати 2-пунктовых отбивок перед высокими знаками препинания типа "; : ! ? “, ” исправления на правильные сочетания знаков градуса, промилле, процента, номера с предыдущим или последующим символом.
|
|
Достоинства OpenType
Итак, мы рассмотрели некоторые достоинства OpenType/ATSUI-шрифта.
Прежде всего к ним относится то, что он:
- является бинарно-совместимым кросс-платформенным, что позволяет гарантированно получить одинаковый результат как на Macintosh-, так и на Windows-платформе, экономит средства (используется одна копия шрифта), снижает трудозатраты (документ является кросс-платформенным, так как основан на Unicode encoding, метрики шрифта/символов одни и те же) при необходимости переноса публикации с одной платформы на другую;
- основан на Unicode;
- поддерживает дополнительные возможности типографики — ligatures, old style, capitel, historic variant, typographic rules;
- позволяет иметь в одном шрифте и ATSUI- и OpenType-инструкции для поддержки ATSUI-приложений. Таблицы Apple ATSUI могут присутствовать в OpenType-шрифтах параллельно с OT features-таблицами.
|
|
UNIX
Использование OpenType-шрифтов и технологий на UNIX (Sun Solaris, IBM AIX, HP HP-UX) и UNIX-подобных платформах типа Linux весьма перспективно, однако очень далеко от практической реализации и тем более от реального использования в UNIX-менеджменте документов и UNIX-публикациях.
Наиболее близко, на наш взгляд, к возможности использовать OpenType подошла фирма Sun в операционной системе Solaris 8 и ее будущей версии 9, имеющих очень высокий уровень имплементации Unicode для поддержки новых языковых групп и локалей. Тем не менее ни существующая в Solaris реализация поддержки Type 1 (надстройкой над форматом которого в некотором смысле является шрифт OpenType CFF), ни версия Adobe Display PostScript, используемая там как расширение X/Window-CDE, не основаны на Unicode, не умеют его использовать и сильно отстают в плане его поддержки от даже старой IBM OS/2 v.3.0 (1995). Использование же на Sun Solaris TrueType и его расширений, в том числе OpenType, тесно связано с реализованным уровнем поддержки OT в Java (Sun) и пока еще далеко от практического применения. Пользователи Solaris 8 и StarOffice 5.2 под кириллическими локалями с использованием Unicode TrueType хорошо знакомы с рядом непреодолимых просчетов программистов и QA-инженеров Sun на этом пути.
В 1996 году фирма HP сделала публичное заявление о полной поддержке формата OpenType в будущих версиях HP-UX, однако пока даже для последней версии — HP-UX 11i это остается не более чем намерениями. Аналогична ситуация и с новейшей версией IBM UNIX — AIX 5.0.
Наиболее передовая в области поддержки новых языковых групп версия Linux Mandrake (http://www.mandrake.org/) в возможностях поддержки OpenType (так же как и другие подобные операционные системы), споткнулась о проблемы необходимости согласованного между различными группами GNU-разработчиков портирования всех системных библиотек для полной поддержки Unicode 3.1. Процесс этот начался не сегодня, но пока еще очень далек как от завершения, так и от достижения полного согласия между разработчиками. Отметим, что Linux Mandrake наряду со стандартными кириллическими языковыми группами поддерживает армянскую, грузинскую, казахские локали.
Практическое применение OpenType и использование различных инструментов для создания и модификации таких шрифтов для некоторых языковых групп нашего региона мы рассмотрим в отдельной статье, используя уникальные возможности InDesign 1.5 Macintosh- и Windows-версий, и мощных инструментов для построения OpenType — FontLab 4, Adobe FDK и MS VOLT.
КомпьюАрт 7'2001