From: "Alexey Kryukov" <CyrTeX-ru@vsu.ru>
Received-SPF: neutral
 receiver=relay1.vsu.ru; client-ip=80.240.208.106; envelope-from=anagnost@yandex.ru
To: "Cyrillic TeX Users Group" <CyrTeX-ru@vsu.ru>
Subject: Re: shape of the yat, AFMtoENC
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <list-101518550@relay1.vsu.ru> <list-101850150@relay1.vsu.ru>
In-Reply-To: <list-101850150@relay1.vsu.ru>
MIME-Version: 1.0
Content-Disposition: inline
Date: Sun, 13 Jul 2008 19:41:29 +0400
Content-Type: text/plain;
  charset="koi8-r"
Content-Transfer-Encoding: 8bit
Message-Id: <200807131941.29131.anagnost@yandex.ru>

On Friday 04 July 2008, Лидовский Владимир wrote:

> Возможно и самому придется им попользоваться, но пока
> хватает обычного ТеХ и пугает некоторая несовместимость XeTeX со
> старым добрым и тщательно проверенным ТеХ. 

Вот все пугают несовместимостью, но никто не объясняет, о какой именно
совместимости идет речь. Совместимость на уровне команд компилятора?
Ну так она сама собой разумеется. Возможность откомпилировать старые
файлы? Тут некоторые проблемы, конечно, возможны, но не более, чем
при смене версий пакетов, используемых с обычным (pdf)tex. Никогда
не забуду, как после обновления Бабеля оказалось, что действие
команды \selectlanguage, помещенной в сноску, почему-то этой сноской не
ограничивается, а распространяется и на дальнейший текст. Да и какой 
смысл именно для этой цели использовать XeTeX? Он ведь не один
устанавливается, а в составе полного дистрибутива, где присутствует и
pdftex, и традиционный кнутовский tex.

Или речь идет о совместимости по пакетам? Что ж, пакеты, специально
ориентированные на поддержку различных языков/кодировок, конечно,
приходится выкидывать или заменять, т. к. меняется сама модель поддержки
этих языков. Но, право же, это благо, т. к. в результате можно
избавиться от большого количества граблей, кем-то когда-то разложенных
во имя этой самой "совместимости". Ну вот, скажите, на милость, зачем
французскому Бабелю лезть в кириллические шрифты LWN за
кавычками-елочками, когда в кодировке T1 есть не хуже? А он лезет,
в результате чего обеспечивается "совместимость" со старыми шрифтами, но
зато невозможно использовать французский и русский в одном документе.

> Речь была о том, что у меня возникли проблемы с подключением
> произвольного Type 1, ttf и др. шрифтов к TeX. Оказалась, что нет
> практически ничего для быстрой инсталляции таких шрифтов. Поэтому и
> появилась утилита AFMtoENC, которая эту проблему как-то решает.

Ну был fontinst, он тоже довольно удобен. Видите ли, на самом деле,
прикрутка шрифтов к TeX для опытного пользователя и раньше не составляла
особой проблемы. Проблема в другом: мне просто не нравится модель, при
которой приходится разбивать полноценный юникодовый шрифт на отдельные
8-битные блоки, к тому же довольно странно составленные. Я уже не раз
высказывал свое мнение о кодировке T2A: это ж надо было умудриться 
не просто позаботиться о тюркских и др. языках, но еще к тому же и
пожертвовать ради них нормальными славянскими символами из cp1251
(предложив набирать их с помощью акцентов или унифицировав 
с латинскими). И благо бы азиатские символы были широко востребованы,
но ведь нет: пакетов языковой поддержки нет до сих пор, в шрифтах на
этих местах -- черные дыры. Зато во всех славянских языках, кроме
русского, теперь имеем проблемы с поиском в PDF. А если мне нужно
набирать текст с "ятями", так и вовсе предлагают пользоваться ублюдочной
T2D, для которой тоже нет и не может быть нормальной шрифтовой
поддержки. А смысл грузить новую кодировку, если мне всего-то и нужна из
нее пара символов?

Но мало того: всё это кодировочное хозяйство не только выглядит странно,
но к тому же так и не стало общепризнанным стандартом. Многим не
нравится inputenc с его активными символами, многие предлагают свои
модели русификации, основанные то на KOI8, то на какой-нибудь
cp1251-light. А Вы говорите, совместимость. А с Юникодом таких проблем
нет: он один.

> > Можно. Вообще-то как inputenc при использовании кодировки T1, так
> > и пакет xunicode для XeTeX как раз и стараются подставлять готовые
> > композиты, если таковые доступны. Однако создатели Unicode давно
>
> Ну тут их Кнут явно опередил! ;-) 

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

> И есть еще SIL (если вы имеете 
> отношение к лингвистике, то аббревиатуру наверное знаете).

Знаю хотя бы потому, что именно под крышей этой организации 
до последнего времени работал главный разработчик XeTeX :)

> Это очевидно, но в Unicode 2^32 кодов -- теоретически должно хватить
> и на "композиты".

Во-первых, не хватит, если учесть все возможные комбинации с двумя
и более акцентами.

Во-вторых, есть принципиальное решение разработчиков стандарта: новых
композитов *не кодировать*. Я, как разработчик шрифтов, это решение
всячески приветствую, т. к. иначе пришлось бы в каждой новой версии
шрифта плодить кучу символов-клонов, при том что уследить за
корректностью позиционировани их компонентов было бы абсолютно нереально
для одного человека. Лучше уж сосредоточиться на уточнении правил
позиционирования комбинируемых акцентов, которые подходили бы для
большинства стандартных случаев.

В-третьих, Вы, возможно, не в курсе, что все имеющиеся композиты с точки
зрения стандарта считаются эквивалентными определенным
последовательностям вида <базовый символ + один или несколько акцентов>.
В теории тот и другой вариант представления акцентированного символа
должен обрабатываться программами одинаково, хотя на практике, конечно,
этого не всегда легко добиться.

> звучит очень революционно, как о костях старого мира. "Все они"...

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

> А почему только в T1? Хотя, конечно, в unicode диакритик больше, но
> это ведь вопрос не принципиальный, а вопрос востребованности...

Потому что на практике дело ограничивается ею (кстати, в основном тот
же набор и в T2*). Конечно, в каких-нибудь tipa акцентов побольше, но
тут мы уже скорее всего будем ограничены стандартным дизайном в стиле
cm (ведь при разработке шрифтовых пакетов редко кто учитывает эту
кодировку). Плюс еще надо засорять исходник командами для набора этих
акцентов, что отрицательно скажется на его читабельности (ибо далеко
не все такие команды интуитивно понятны).

> Никто не мешает использовать естественную кодировку шрифта или
> разработанную самостоятельно. 

_Нельзя_ использовать естественную кодировку, если это Юникод.

> Конечно, иметь несколько tfm для одного 
> файла шрифта - это явные издержки технологии, но ведь об этом после
> установки шрифта можно уже и не думать. Абсолютное большинство
> текстов на алфавитных письменностях кодируется байтом на знак - 

Не расписывайтесь за абсолютное большинство. О такой "экзотике",
как сирийский или арабский, я не говорю, но даже для греческого
8-битной кодировки в сущности недостаточно. Да, большинство
акцентированных символов в таблицу вроде как и влезло, но набирать
их приходится с помощью лигатур, а это разбивает кернинг, в том
числе и в важных случаях. Со славянским та же история: акцентов
много, набирать каждый с помощью символа backslash замучаешься.
Только, в отличие от греческого, тут уж для всех акцентированных
комбинаций заведомо нет места в таблице. Приходится идти на
такие извраты, как акценты в нулевую ширину -- трюк знакомый
по текстовым процессорам, но абсолютно противоречащий идеологии TeX.
И это ведь не юникодовые акценты с их тонким позиционированием,
а просто тупой расчет на перекрытие акцента с предшествующим знаком.

> само 
> существование UTF-8 является этому наглядным примером.

Поясните, каким образом существование UTF-8 (в которой все
символы кроме блока ASCII кодируются как минимум двумя байтами)
может служить этому наглядным примером.
 
> все к Unicode - это маловероятная перспектива. Как всегда есть
> высокие объединяющие концепции, но... Есть еще и проблема ввода
> текстов.

Об этом тоже много можно говорить. Мне представляется, что удобнее
воспользоваться специальной раскладкой, либо, если это единичный
символ, вставить его из таблицы, нежели писать длинные командные
последовательности типа \cyryat (а если этот \cyryat на каждой
строчке?). Тот же греческий в (pdf)LaTeX сейчас набирается с латинской
раскладки, и выглядит это примерно так: >En >arq~h| >~hn <o l'ogos...
Набирать-то, может, и удобно, но вот читать замучаешься. Плюс еще
проблема с конвертацией текста между TeX'ом и другими программами,
которая для подобных способов представления никем толком не решалась.

> Установка нового шрифта в любой системе потребует к себе некоторого
> внимания. Или вы хотите, чтобы все шрифты оформлялись в коробочные
> дистрибутивы с механизмом P&P?

Установка шрифтов во всех современных системах делается через интуитивно
понятный графический интерфейс. Этого совершенно достаточно.

> > Поясните, что Вы имеете в виду. С моей точки зрения, проблема прямо
> > противоположная: достать из шрифта мы можем только те символы,
> > которые прописаны в ENC-файле, то есть ровно 256 штук за раз и
> > никак не больше.
>
> Похоже, что pdfTeX грузит их все (может 100, а может 10000) - это,
> если я правильно понял, весьма серьезный недостаток.

Можете ли дать ссылку на то место, где это написано?

> > И, кстати, что Вы в данном случае понимаете под Open Type шрифтами
> > (спрашиваю потому, что этот термин может иметь разные значения)?
>
> Именно то, о чем написано в pdfTeX manual.

Интереса ради посмотрел pdfTeX manual, и не нашел там ни одного
упоминания об OpenType. Возможно, мы с Вами говорим о разных документах.
Посему опять же не помешала бы ссылка или цитата.

> > Да при том, что он тоже принципиально восьмибитный. Это не говоря
> > уж о том, что он просто не нужен, т. к. все необходимые данные уже
> > содержатся в TTF/OTF.
>
> А как быть с MF-шрифтами?

Так их же никто не отменял: с MF и Type 1 тот же XeTeX по-прежнему
работает через TFM. Для Type 1 это, кстати, тоже вполне законно,
т. к. метрики к этим шрифтам в любом случае хранятся отдельно.
Другое дело, что из-за принципиальной восьмибитности обоих форматов
их применимость в XeTeX в основном ограничивается западными языками,
т. к. едва ли разумно смешивать в одном пакете две совершенно разные
модели поддержки одного алфавита (напр. кириллицы).

> Да, конечно, здесь XeTeX похоже чемпион, но постоянная и полная
> поддержка Unicode нужна наверное только строителю новой вавилонской
> башни. :-) Обычным юзерам Unicode необходим только для
> единовременного включения одного-другого редкого знака.

А также для того, чтобы документы с "единовременно включенными" редкими
знаками сохраняли совместимость между собой.

> делать на основе программ SIL (они уже явно устарели). Поэтому привел
> данные, опираясь на формальный источник - LaTeX-пакет unicode. На
> основании этого источника в T2D нет уникодов для позиций
> 1d-1f,80,81,84,85,88,94,96,a0,a1,a4,a5,a8. 

Не надо верить формальным источникам :) Давайте смотреть:

80/a0 -- обычное кириллическое "а", неизвестно зачем продублированное;

81/a1 -- CYRILLIC LETTER IOTIFIED A U+A656/A657, есть в Unicode 5.1;

84/a4 -- CYRILLIC LETTER DJERV U+A648/A649, есть в Unicode 5.1;

88/a8 -- спорный символ: попытка как-то обозначить тот факт, что
славянское десятичное i в нижнем регистре должно писаться с двумя
точками. Заглавная форма искусственно сочинена так, чтобы чем-то
отличаться от обычного I. Шанса на признание в Юникоде в качестве
особого символа эта буква, видимо, не имеет, тем более, что i
с двумя точками и так имеется. Так или иначе, ничто не мешает нам
при перекодировке шрифта в T2D заполнять эти слоты стандартным I 
и украинским "йи";

85/a5 -- вариантная форма обычного "н", которая по этой причине не имеет
шансов на включение в Юникод;

94/b4,96/b6 -- то же самое;

1d -- CYRILLIC KAVYKA U+A67E, есть в Unicode 5.1;

1e/1f -- не имеют шансов на включение в Unicode, т. к. представляют
собой сочетания тонкого придыхания с ударениями, с помощью которых 
и должны набираться. Правда, тут есть общая проблема, связанная с тем,
что TeX'овские акценты по смыслу являются комбинируемыми, но при этом
должны центрироваться в ячейке глифа. Т. е., конечно, можно сопоставить,
например, титло символу U+0483, но в шрифте этот символ, скорее всего,
будет иметь нулевую ширину и смещение влево, что сделает его непригодным
для использования в TeX.

> Позиции 86, 92, a6 и b2 
> заполнены только в Unicode 5.1 (где шрифты с их поддержкой!?).

Думаю, не заставят себя ждать.

> Позиции 9b и bb могут заполнены юникодами 0510 и 0511, но не уверен,
> что это верно.

Полагаю, что да.

-- 
Regards,
Alexej Kryukov <anagnost at yandex dot ru>

Moscow State University
Historical Faculty