From: "Alexey Kryukov" <CyrTeX-ru@vsu.ru>
Received-SPF: softfail
 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: Unicode, AFMtoENC
Date: Sun, 17 Aug 2008 13:18:08 +0400
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <list-101518550@relay1.vsu.ru> <list-107219042@relay1.vsu.ru> <list-108980491@relay1.vsu.ru>
In-Reply-To: <list-108980491@relay1.vsu.ru>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="koi8-r"
Content-Transfer-Encoding: 8bit
Message-Id: <200808171318.09280.anagnost@yandex.ru>

On Tuesday 12 August 2008, Лидовский Владимир wrote:
>
> Cистема fontinst имеет весьма много возможностей по документированию.
> Механизм  команды \aliased теоретически решает проблему, но в той
> версии fontinst, что выложена на CTAN соответствующие пары не
> прописаны. 

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

> Спасибо за ценное замечание. В новой версии программы эта поддержка
> добавлена. Эта кодировка не поддерживалась из-за того, что она не
> используется напрямую, а через пакет textcomp. Получается, что ее
> использование может потребовать дополнительных согласований с этим
> пакетом, что уже не даст в общем случае возможность назвать такую
> инсталляцию БЫСТРОЙ. 

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

> Кроме того, до половины символов TS1 -- это 
> весьма специфические вариантые формы (capital breve, ...), которых в
> Unicode нет, что делает их поддержку заменой на имеющиеся там (и в
> T1) знаки почти бессмыссленной. 

Заглавных акцентов действительно нет в Unicode, но в большинстве шрифтов
их именуют согласно одной из двух устоявшихся схем: либо "Acute", 
"Grave" и т. д., либо (в более новых шрифтах) "acute.cap", "grave.cap" 
и т. д. Так что с ними как раз всё довольно просто. То же касается
минускульных цифр и некоторых других вариантных форм.

> Есть там и символы, для которых в 
> Unicode вообще нет соответствия. Получилось, что реально через
> Unicode можно работать только с третью TS1.

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

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

Вообще не понимаю, при чем тут babel.sty. Разве там задается список 
поддерживаемых кодировок?

> А насчет cyrillic bundle, то разве это необходимо?

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

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

Владимир, ну скажите на милость, как можно, не зная ни греческого языка,
ни обстоятельств появления данного знака в кодировке, утверждать, что
это именно символ? Если б это было так, то, наверное, он понадобился бы
еще кому-нибудь, кроме создателей CB-шрифтов (т. е. Клаудио Беккари и
Апостолоса Сиропулоса)? Почему тогда ни TLG, ни PHI (составители
исчерпывающих баз данных по греческим текстам и надписям) не потрудились
составить заявку на его включение в Unicode?

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

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

> Есть "тильда" сама по себе, есть "тильда", налагаемая сверху, есть
> "тильда", налагаемая снизу, есть еще "маленькая тильда" и прочие
> "тильды", возможно появятся какие-то новые "активные тильды". И все
> это относится ко всем диакритикам. Неужели не чувствутся какая-то
> порочность cамой идеи? Гораздо практичнее было бы иметь одну "тильду"
> и контольные коды, применимые не только к "тильде". Речь о том, что с
> давних пор принято отделять мухи от котлет. Зачем жестко связывать
> картинку с действием? У используемого метода только одно преимущество
> -- экономия нескольких байт.

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

> И американец может прочитать CCCP как си-си-си-пи, ну и что? Это как
> раз и показывает, что буквы одинаковые. Понятно, что доказать тут на
> гуманитарном уровне ничего нельзя, но если предлагают различать
> французкую и немецкую воду, то это скорее лирика чем наука. Поэтому
> речь только о банальном прагматизме и стремлении к комфорту -- если
> пользователь не может визуально отличить два символа, то очень
> некомфортно, когда компьютер навязывает такое различение.

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

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

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

> > Глиф -- воплощение идеи символа, но сам по себе он не символ.
>
> Интересная позиция. Сократ как воплощение идеи человека, но ... Или я
> чего-то не понял?

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

> Композит предлагает идеальное с визуальной точки зрения решение --
> никакой самый идеальный алгоритм не даст идеала в 100% случаях.

Этот аргумент работает против Вас. Да, конечно, я не смогу охватить
своим алгоритмом 100% случаев, но, как Вы сами признаете, я тем более
не смог бы включить в свой шрифт 100% акцентированных комбинаций.
А между тем алгоритм написать легче, работать он будет более эффективно
и не испортится от случайного смещения частей композита. Например,
я уверен, что мой шрифт OldStandard может использоваться
для набора литовских словарей с полной акцентуацией (а там тех
акцентированных символов на полную 256-символьную таблицу набралось бы).
А вот будь в Юникоде специальный блок для акцентированного литовского,
я определенно не стал бы его поддерживать.

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

> Хотя, если использовать что-то типа виртуальных шрифтов ТеХ...

Фактически Вы здесь предлагаете заменить более точный метод
позиционирования акцентов менее точным. Помню я, как эти виртуальные
шрифты делалить в fontinst: всё было построено на предположениях
относительно того, на каком проценте ширины надо размещать акцент.
Естественно, это нормально работало далеко не для всех гарнитур.
А вот OpenType с его якорными точками, конечно, требует усилий от
шрифтового дизайнера, но и результаты дает идеальные.

> Но уже 8 бит не дают совместимости: 8859-1 замещается 8859-15. 8-11
> бит -- это зона 2-байтных UTF-8 кодов. 

Во-первых, никто не ставил задачи совместимости со всеми будущими
кодировками. Во-вторых, iso8859-15 -- мертворожденная кодировка: когда
ее стали использовать в *nix и web, впору было уже переходить на UTF-8.
В-третьих, cp1252 гораздо более популярна, а это не что иное, как
расширенная iso8859-1.

> > Иными словами, вместо единого универсального алгоритма разбора
> > текста перед поиском Вы предлагаете использовать длинные списки
> > исключений. Боюсь, такое решение не нашло бы понимания среди
> > программистов.
>
> Все сводится к очень быстрой работе с автоматными (регулярными)
> выражениями. Странно, что их внедренее идет столь медленно. Тут
> какая-то проблема, но исключительно гуманитарного порядка.

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

> Посмотрите на регистры в Unicode. Где там логика? 

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

> Есть еще 
> использовавшаяся с OS/2 cp855. 

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

> Кстати, в кои-8 с регистрами все также как и, например, в cp1251 или
> iso 8859-5.

Нет. В koi заглавные идут после строчных. Такого нет ни в одной
нормальной кодировке.

> А отсутствие знаков других языков... Как много 
> русскоговорящих людей в документах на русском нуждается в сербских
> буквах? 

Ориентация только на русскоговорящих людей -- это и есть один из 
принципиальных недостатков koi.

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

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

> И эта 
> проблема легко могла быть решена, как это сделали с koi8-u. Там ведь
> осталось много почти свободных (псевдографика, математика) позиций.

Бесполезная псевдографика, добавлю я. Ею ведь никто не пользовался, 
т.к. даже на *nix для этой цели обычно служила cp866.

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

Никому, разумеется. Встречный вопрос: а чем Вам мешает тот факт, что
оно таки находится в позиции 1006?

> Да и 
> тем это бы никаких проблем не доставило. Речь о том, что по каталогу
> символов можно потом специалистам строить те или иные СВОДНЫЕ таблицы
> по нужным для тех или иных целей категориям, например, испанский или
> украинский алфавиты.

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

> Зачем рядом? Вся проблема именно в жестких границах блоков -- они и
> превращают, повторю ваши слова, Unicode в помойку. Создатели Unicode
> взяли на себя слишком много.

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

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

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

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

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

Так что забудьте об этой химере "естественной кодировки". На самом деле
для TTF/OTF важна только таблица cmap. Для Type 1 -- либо словарь
Encoding (но в нем ровно 256 элементов), либо юникоды, восстановленные
на основании имен глифов.

> А некоторая информация, в частности, о Unicode (не всегда 
> для ttf и крайне редко для Type1) действительно хранится в отделных
> таблицах.

А еще, говорят, крокодилы летают, но только низенько-низенько :) Нет
в Type 1 информации о Unicode: никакой и никогда. Как, впрочем,
нет там и никаких таблиц. Напротив, TTF/OTF состоят из таблиц
_полностью_. Так что _любая_ информация, хранящаяся в таком файле,
обязательно находится в какой-нибудь "отдельной таблице".

> Но речь то была о преимуществах Unicode над локальными таблицами
> кодировки. Моя позиция в том, что замена локальных таблиц на Unicode
> решает только очень узкоспециальные проблемы и создает новые. Unicode
> со всеми своими недостатками вещь очень полезная и в отсутствие
> альтернативы необходимая, но далеко не достаточная решения всех
> проблем работы с текстами.

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

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

Moscow State University
Historical Faculty