From: "=?KOI8-R?B?7MnEz9fTy8nKIPfMwcTJzcnS?=" <CyrTeX-ru@vsu.ru>
Received-SPF: pass
 receiver=relay1.vsu.ru; client-ip=213.180.200.60; envelope-from=litwr@yandex.ru
To: cyrtex-ru@vsu.ru
In-Reply-To: <list-110043470@relay1.vsu.ru>
References: <list-101518550@relay1.vsu.ru> <list-107219042@relay1.vsu.ru> <list-108980491@relay1.vsu.ru> <list-110043470@relay1.vsu.ru>
Subject: Re: Unicode, AFMtoENC
MIME-Version: 1.0
Message-Id: <659591219307363@webmail3.yandex.ru>
Date: Thu, 21 Aug 2008 12:29:23 +0400
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=KOI8-R

> Вообще-то за кириллицу отвечает не базовый fontinst, а дополнение
> к нему, известное под именем T2. Так вот, заглядывали ли Вы в файл
> cyralias.tex из этого пакета?

Конечно, именно об этом дополнении и была речь. А в упомянутом файле действительно прописаны некоторые соответствия для Type 1 шрифтов, сделанных весьма давно. Если вы найдете хоть один ttf-шрифт со схемами именования из этого файла, то это будет чем-то почти невероятным. Схем, используемых в ttf-шрифтах, там нет. :-(
  
> > Эта кодировка не поддерживалась из-за того, что она не
> > используется напрямую, а через пакет textcomp. 

> Хм... Эдак ведь можно сказать, что T1, T2* и т. д. тоже поддерживаются
> не напрямую, а через пакет inputenc. Но как inputenc, так и
> textcomp -- пакеты стандартные, их не нужно устанавливать дополнительно.
> Какие же тут еще дополнительные согласования?

А вы ни в чем не запутались? T1, T2* и нек. др. используются через пакет fontenc, а inputenc - это только для удобства ввода. TS1 же вводится не через упомянутый, а через отдельный пакет, фиксирующий не только кодировку, но имена семейств шрифтов и т.п., что и потребует согласований.
 
> Заглавных акцентов действительно нет в Unicode, но в большинстве шрифтов
> их именуют согласно одной из двух устоявшихся схем: либо "Acute", 
> "Grave" и т. д., либо (в более новых шрифтах) "acute.cap", "grave.cap" 
> и т. д. Так что с ними как раз всё довольно просто. То же касается
> минускульных цифр и некоторых других вариантных форм.

Опять спасибо. Придется наверное добавлять эти данные в AFMtoENC, сочиняя локальные "уникоды".

> Ну, при установке шрифтов в формате Type 1 обычно так и получалось, что
> TS1 закрыта не более чем на треть. Хотя "можно работать только с
> третью" -- это преувеличение: всё же в большинстве случаев там
> обнаруживаются либо юникодовые эквиваленты, либо (как в случае с
> заглавными акцентами) глифы, традиционно поддерживаемые Adobe и вслед
> за ней другими производителями.

Это относится и к ttf/otf. А традиционно поддерживаемые глифы без специальных уникодов в технологиях, основанных на Unicode выглядят малополезными.

> > Почти уверен, что если бы Вы эти занялись, то все вопросы бы решились
> > за максимум месяц. Добавить в babel.sty одну строчку и нарисать об
> > этом тем, кто его поддерживает. 
> Вообще не понимаю, при чем тут babel.sty. Разве там задается список 
> поддерживаемых кодировок?

Извиняюсь, имел в виду две строки russianb.ldf (можно еще аналогичную операцию проделать и для ukraine.ldf и нек. др. языков, но в этих странах свои специалисты наверное есть). Если нужно просто избежать конфликта, то можно просто прописать команду 
\def\cyrillicencoding{T2D} в преамбулу определения T2D или в каждый документ с T2D.

> Ну так cyrillic bundle -- это именно тот компонент, за счет которого 
> и обеспечивается поддержка кириллицы бабелем.

Но это ведь не есть нечто обязательное - можно расширить географию для бабеля. А если нужен именно bundle, то что мешает вам связаться с его администратором?

> > > Добавлю, что в 7-й позиции стоит та
> > > самая сомнительная вариантная форма: символ, который называется
> > > vardigamma, но в качестве дигаммы неузнаваем.

> > Два разных символа, а уникод один. :-(

> Владимир, ну скажите на милость, как можно, не зная ни греческого языка,
> ни обстоятельств появления данного знака в кодировке, утверждать, что
> это именно символ? Если б это было так, то, наверное, он понадобился бы

Есть кодировка, а в кодировках указывают именно символы. Места ведь много и авторы достаточно авторитетны. Всегда будут некоторые спорные вопросы, но зачем же работать мешать? Как Вы, например, введете эти два знака в XeTeX?

> еще кому-нибудь, кроме создателей CB-шрифтов (т. е. Клаудио Беккари и
> Апостолоса Сиропулоса)? Почему тогда ни TLG, ни PHI (составители

Не будьте таким догматичным - позвольте авторам определять, что они считают кодировкой, а что нет. Лет 20 назад Unicode был большим шагом вперед...
 
> исчерпывающих баз данных по греческим текстам и надписям) не потрудились
> составить заявку на его включение в Unicode?

Боятся с ним связываться - обычное дело. Ждут возможно, что этот мутный стандарт заменят на что-то более демократичное. К сожалению, наверное, не дождутся. :-( Как-то мало повсюду инициативы... Unicode жил, Unicode жив, Unicode будет жить! Ура, товарищи!!!

> > (а в таблицы кодировки ставят именно символы)

> В Unicode -- да. Что касается TeX'овских и прочих 8-битных таблиц, то их
> создатели, как правило, не осознавали разницу между глифом и символом,
> и потому лепили туда, что придется.

А что вы скажите об уникодах в диапазоне 1d400-1d7ff? Можно найти много таких примеров. Или вы полагаете, что вариации разрешаются тoлько для латиницы? И откуда такое неуважение к тем, кто не стремился "к светлому будущему" вместе с Unicode или попросту не знает как себя вести с "великим и незаменимым" консорциумом?

> Маленькая тильда -- это как раз spacing accent, добавленный ради
> совместимости со старыми стандартами. Связи между просто тильдой и
> акцентом "тильда" не вижу никакой: с тем же успехом можно было бы
> унифицировать, скажем, акут со слэшем. К тому же тильда -- символ,
> широко используемый в программировании (в т. ч. и в TeX), и навешивать
> на него какие-то возможности сложного контекстно-зависимого поведения
> было бы чревато непредсказуемыми последствиями. Тильда вверху и внизу --
> опять же IMHO совершенно разные акценты, да и экономия от унификации
> была бы грошовая. Зато представьте, каково было бы вводить с помощью
> таблицы сначала акцент, а потом контрольный код к нему (невидимый!).

Вы опять путаете ввод и внутреннее представление. Речь была только о внутреннем представлении и о недопустимости жесткого смешивания действий и данных - принцип разделения известен еще со времен мануфактур. В программировании давно (с 70-х) известна необходимость выделения алгоритмов и данных, Unicode здесь отбрасывает нас на уровень 50-х. Неужели вы осмелитесь утверждать, что в уникодах "тильда сверху", "посередине" и "снизу" сам знак "тильда" выглядит по-разному? А вводить можно совершенно одинаковыми способами при самых разных внутренних представлениях данных.

> Дык, к сожалению, пользователь много чего не может отличить визуально.
> Например, постоянно приходится сталкиваться со знаком "плюс" вместо
> типографского dagger'а. А что, похож ведь. Или вот на пишущей машинке

Ну спутать "кинжал" и "плюс" - тут надо постараться! И вы пишете все же о том, что пользователь чего-то может не доглядеть... Попробуйте, посмотрите на проблему непредвзято и увидите, что у знаков кроме сходства-несходства объективно больше ничего нет, а все остальное определяется контекстом и схоластическим "теоретизированием". Представте себе рыбу, пойманую в одном озере и выпущенную в соседнем. Каждое озеро уникально, но некоторые рыбы могут жить в обоих.

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

Для удобства пользователей эта унификация во многих случаях была бы весьма полезной подвижкой. Проблемы тут только в головах "теоретиков". Не пытайтесь переносить контекст вместе со знаком.

> Я к тому, что помечать латинскую аббревиатуру (или, скажем, римские
> цифры) в массиве русского текста другим языком -- это всё же перебор.
> А если так, то откуда система узнает, что "A" в сокращении "IBM PC AT"
> должно быть латинским?

Вся эта фраза должна быть в контексте английского языка. И в чем тут проблема? Обычная аккуратная разметка...

> Ну, если угодно. Символ -- это абстракция: понятие о знаке, который
> выглядит определенным образом и имеет определенное значение. Глиф --
> это конкретная картинка, отвечающая за изображение того или иного
> символа. Например, буква "А" есть символ, а буква "А" из шрифта
> Times New Roman есть глиф.

Ну, хорошо. Глиф - не символ, а Сократ - не человек. О вкусах не спорят...

> > Хотя, если использовать что-то типа виртуальных шрифтов ТеХ...
> Фактически Вы здесь предлагаете заменить более точный метод
> позиционирования акцентов менее точным. Помню я, как эти виртуальные

Опять меня не поняли, я о том, что если оставить разработчикам только их национальные шрифты, на которые у них заведомо хватит сил со всеми диакритиками, то создание глобальных Unicode-шрифтов станет чем-то почти бессмысленным и возможным только в рамках технологий, близких виртуальным шрифтам TeX. А так получается, что любой разработчик шрифта пытается сделать сразу все и немедленно и думает не столько о качестве, сколько о "костылях" типа накладываемых знаков.
 
> В-третьих, cp1252 гораздо более популярна, а это не что иное, как
> расширенная iso8859-1.

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

> > Все сводится к очень быстрой работе с автоматными (регулярными)
> > выражениями. Странно, что их внедренее идет столь медленно. Тут
> > какая-то проблема, но исключительно гуманитарного порядка.
> Пришлось бы формировать монструозные регулярные выражения для поиска
> самых простых слов. Скажем, ищем слово с буквой "a", и к этой несчастной
> букве "a" цепляем еще тысчонку-другую акцентированных вариантов. Но

Но это все должно делаться автоматически для УДОБСТВА пользователей и НИКАКОЙ технической проблемы здесь нет. Нужно, конечно, всегда учитывать контекст языка.

> самая главная проблема даже не в этом, а в том, что списки
> акцентированных эквивалентов пришлось бы обновлять с выходом каждой
> новой версии стандарта. В то время как в Unicode основные свойства

Ну этo вообще-то обычное дело - вносить добавления при обновлении стандартов. Это верно для любой технологии.

> уже закодированных символов зафиксированы и не подлежат изменению.

Но вы писали о появлении каких-то новых свойств, неужели не символов?

> > Посмотрите на регистры в Unicode. Где там логика? 
> Ее там и нет. Но то Unicode: он один. А 8-битные кодировки делались
> сериями, и именно поэтому в них желательно было выдерживать некоторое
> единообразие. За счет этого единообразия, в частности,

Почему желательно? Единообразие ради единообразия, от которого потом все-равно следует отказаться? Упоминалась еще cp855 с совершенно необычной логикой расположения знаков кириллицы. Только очень жалкая пародия на ПО может использовать информацию об естественном расположении символов в кодировке - нормальное ПО использует специальные таблицы для сортировки, в частности, - это было даже в DOS.

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

Ну есть еще Ё, умлауты и т.п. Ну не порядок важен, а наличие символов - извините за повторение.

> > Кстати, в кои-8 с регистрами все также как и, например, в cp1251 или
> > iso 8859-5.
> Нет. В koi заглавные идут после строчных. Такого нет ни в одной
> нормальной кодировке.

Точно, но видеть в этом что-то принципиальное, очень необычно. Какая разница?! Что тут ненормального для практической работы?

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

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

> > Вы меня не поняли, я о том, что чем было бы плохо, если бы И имело
> > позицию 1005, а Й --- не 1006, а допустим 1344? Кому бы это мешало,
> > кроме разве разработчиков системного программного обеспечения? 
> Никому, разумеется. Встречный вопрос: а чем Вам мешает тот факт, что
> оно таки находится в позиции 1006?

Мне не мешает, но зачем этот малозначительное положение навязывается? Это ведь и есть что-то похожее на малонужную "естественную" кодировку шрифта, которой "давят" из Unicode.

> > Да и 
> > тем это бы никаких проблем не доставило. Речь о том, что по каталогу
> > символов можно потом специалистам строить те или иные СВОДНЫЕ таблицы
> > по нужным для тех или иных целей категориям, например, испанский или
> > украинский алфавиты.
> Ну составляйте для себя такие таблицы, если нужно. Разделение на блоки
> здесь только помогает, т. к., во-первых, позволяет сузить круг поиска
> нужных символов, сведя его к нескольким блокам, а во-вторых, многие
> блоки еще и разбиты на подмножества с указаниями на то, для чего каждое
> подмножество служит. Например, "Letters for Old Cyrillic", "Letters for
> Old Abkhasian orthography"... Да и к самим символам часто имеются
> соответствующие пояснения.

Было бы гораздо удобнее иметь множества атрибутов для каждого символа и возможность делать выборки по выбранным критериям.

> Попытаюсь понять Вашу мысль. Предположим, UTC послушался Вас и решил
> отказаться от жестких границ блоков. Поэтому при обсуждении вопроса
> о добавлении очередной порции латинских букв принимается решение:
> одну засунуть к китайским иероглифам, другую -- к дингбатам, третью --
> к символам деванагари. Зачем? А просто так, чтобы жизнь медом не
> казалась. Этого Вы добиваетесь, что ли?

Предлагается просто регистрировать символ вместе с набором атрибутов к нему, а не искать для него места попривелегированнее. А нужные тем или иным пользователям блоки получались бы по запросам к такой БД. Неужели Вам существующая система нравится больше?

> > Ведь даже сообщество
> > пользователей ТеХ не пытается зафиксировать там используемые символы
> > -- много мороки из-за как несовершенства структуры Unicode, так и
> > из-за связанных с этим бюракратических штучкек.
> Здесь надо разбираться с каждым символом отдельно. Возможно, окажется,
> что символ либо не имеет смысла вне TeX, либо невостребован, либо,

Опять какая-то тайная канцелярия. Неужели тот факт, что символ используется в стандартной кодировке ТеХ недостаточен?! Места-то полно! 

> наконец, в действительности представляет собой вариантную форму и потому
> не имеет шанса на включение в стандарт. Вот, например, такая типично
> TeX'овская приблуда, как perthousandzero: кому оно нужно в Unicode,
> если есть готовые perthousand и pertenthousand?

Этот знак скорее связан с единообразием ввода, как некая особенная диакритика. Ведь не во всех шрифтах есть соответствующие символы, а для тех, в которых такие символы есть, в ТеХ есть механизм замены на этот имеющийся "композит". Ведь символа perhundredthousand нет, а этот знак проблему решает. 

> > Давайте посмотрим на вещи практически. Загрузите fontforge или другой
> > редактор шрифтов с любым шрифтом. То в каком порядке будут предложены
> > символы и образует естественную кодировку.

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

Не признаюсь, т.к. не вижу смысла в том, чтобы говорить Вам неправду. Не эксперт, конечно...

> редактору вообще-то _абсолютно всё равно_, в каком порядке показывать
> глифы. Можно, например, тупо взять механический порядок их расположения
> в таблице 'glyf'. Но этот порядок вообще-то никому, кроме шрифтового

Именно о нем и речь.

> редактора не нужен, ибо может быть и абсолютно случайным. А можно

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

> (и именно так делает fontforge) считать кодировку из таблицы 'cmap'.
> А cmap тоже не едина: там этих кодировок может быть и несколько.
> Чаще всего -- три: два раза тот же Unicode в разном формате, а третья --
> 8-битная для Mac. Fontforge в зависимости от настроек может либо
> запросить пользователя, какую именно кодировку взять, либо выбрать ее
> сам в соответствии со своими приоритетами. Далее, если выбран Unicode,
> то он может (опять-таки в зависимости от настроек) либо скрыть незанятые
> слоты, либо показать на их месте пустые квадратики. Так что и с
> непрерывностью тоже никаких проблем.
> Так что забудьте об этой химере "естественной кодировки". На самом деле

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

> для TTF/OTF важна только таблица cmap. Для Type 1 -- либо словарь
> Encoding (но в нем ровно 256 элементов), либо юникоды, восстановленные
> на основании имен глифов.
> > А некоторая информация, в частности, о Unicode (не всегда 
> > для ttf и крайне редко для Type1) действительно хранится в отделных
> > таблицах.
> А еще, говорят, крокодилы летают, но только низенько-низенько :) Нет
> в Type 1 информации о Unicode: никакой и никогда. Как, впрочем,

Возможно вы и правы. Искать прямых опровержений не собираюсь, а косвенное cможете найти в справочнике по формату PDF - там есть указание на использование в словаре для Type 1 шрифтов опционального раздела потока ToUnicode. 

> нет там и никаких таблиц. Напротив, TTF/OTF состоят из таблиц

Не осмелюсь судить о степени Вашей компетентности в работе со шрифтами, но тут вы очень неточны. В Type 1 есть несколько таблиц: FontMatrix, Encoding, ...

> _полностью_. Так что _любая_ информация, хранящаяся в таком файле,
> обязательно находится в какой-нибудь "отдельной таблице".

И нет ни одного скаляра? ;-)

> > Но речь то была о преимуществах Unicode над локальными таблицами
> > кодировки. Моя позиция в том, что замена локальных таблиц на Unicode
> > решает только очень узкоспециальные проблемы и создает новые. Unicode
> > со всеми своими недостатками вещь очень полезная и в отсутствие
> > альтернативы необходимая, но далеко не достаточная решения всех
> > проблем работы с текстами.
> Речь на самом деле была о другом. Я спорил с Вашим утверждением, что,
> мол, UTF-8 придумана в интересах американцев и рассматривает все
> другие языки как второстепенные.

Ну почему же только американцев и тем более чьих-то интересов? Писалось обо всех, использующих английский язык (Гренада, Гамбия,  ...). Неужели не очевидно, что в UTF-8 английский язык поставлен в привелегированное положение? Греческий, русский, иврит, арабский и нек. др. занимают чуть менее почетную "вторую полочку", а вот остальные (например, грузинский или тайский языки) - еще менее почетные позиции. И если английский действительно занимает особенное положение в ИТ, то как вы объясните грузинам, почему их язык на менее почетном месте, чем армянский? Похоже мы начинаем повторяться, но разве все написанное в этом абзаце неочевидно? Более того, могу сейчас опровергнуть ваше утверждение, что для html необходим ASCII и поэтому существующему UTF-8 нет альтернативы: в html можно использовать, например, UTF-16 и ЛЮБУЮ другую стандартную кодировку.