From: "=?KOI8-R?B?7MnEz9fTy8nKIPfMwcTJzcnS?=" <CyrTeX-ru@vsu.ru>
Received-SPF: pass
 receiver=relay1.vsu.ru; client-ip=213.180.200.52; envelope-from=litwr@yandex.ru
To: cyrtex-ru@vsu.ru
In-Reply-To: <list-107219042@relay1.vsu.ru>
References: <list-101518550@relay1.vsu.ru> <list-105187649@relay1.vsu.ru> <list-105790805@relay1.vsu.ru> <list-107219042@relay1.vsu.ru>
Subject: Re: Unicode, AFMtoENC
MIME-Version: 1.0
Message-Id: <1151031218534357@webmail11.yandex.ru>
Date: Tue, 12 Aug 2008 13:45:57 +0400
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=KOI8-R

> > в стандартном пакете поддержки кириллицы t2 для fontinst некоторых
> > схем именования кириллических глиф. Там есть только на основе имен,
> > начинающихся с afii, а всего таких схем не менее 3-4. 
> Это не так. Там именно поддерживаются (через механизм alias) несколько
> различных схем именования. Впрочем, едва ли это так важно: признаться,
> не припомню ни одного шрифта с нестандартными именами глифов, который
> стоил бы трудов по прикрутке к TeX.

Cистема fontinst имеет весьма много возможностей по документированию. Механизм  команды \aliased теоретически решает проблему, но в той версии fontinst, что выложена на CTAN соответствующие пары не прописаны. Их можно, конечно, частично взять, например, из файла glyphtounicode.tex из дистрибутива pdftex, но речь о том, что fontinst это все же средство для скорее эксперта по шрифтам, потому как неэксперту придется потратить весьма много сил даже для беглого ознакомления с новыми очень специальными (только для fontinst) подходами, командами и форматами файлов. И AFMtoENC может лишь косвенно быть полезной в этом случае -- ее задача в БЫСТРОЙ инсталляции ЛЮБОГО шрифта для TeX, используя альтернативный метод чере утилиты afm2tfm и т.п.

> > Кроме того, нет еще T2D. 
> А у Вас, как выяснилось, нет TS1, которая гораздо важнее.

Спасибо за ценное замечание. В новой версии программы эта поддержка добавлена. Эта кодировка не поддерживалась из-за того, что она не используется напрямую, а через пакет textcomp. Получается, что ее использование может потребовать дополнительных согласований с этим пакетом, что уже не даст в общем случае возможность назвать такую инсталляцию БЫСТРОЙ. Кроме того, до половины символов TS1 -- это весьма специфические вариантые формы (capital breve, ...), которых в Unicode нет, что делает их поддержку заменой на имеющиеся там (и в T1) знаки почти бессмыссленной. Есть там и символы, для которых в Unicode вообще нет соответствия. Получилось, что реально через Unicode можно работать только с третью TS1.

> > Что вам мешает подключить свою кодировку к T2. TUG и CTAN вроде бы
> > никогда не отличались бюрократизмом. И использовать, как минимум, в
> > своих документах?
> TUG и CTAN -- возможно. Боюсь, главное затруднение возникло бы не там, 
> а при попытке пропихнуть кодировку в Бабель и cyrillic bundle (напомню,
> что там до сих пор нет T2D, хотя при всех своих недостатках она уж
> точно не хуже какой-нибудь X2). К счастью, мне это уже не нужно.

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

> > Очень интересно! Чем из Unicode заполнить, например, позиции LGR c 2
> > по 7?
> На это Владимир уже ответил. Добавлю, что в 7-й позиции стоит та самая
> сомнительная вариантная форма: символ, который называется vardigamma,
> но в качестве дигаммы неузнаваем.

Два разных символа (а в таблицы кодировки ставят именно символы), а уникод один. :-(
 
> > Хорошо, мне понадобилась буква - как мне ее по-быстрому зафиксировать
> > в Unicode?
> "По-быстрому", конечно, не получится, иначе бы Юникод был куда худшей
> помойкой, чем он является сейчас. Поэтому, если потребность в символе
> однократная, то проще поместить его в пользовательскую область и не
> париться. Но если символ действительно нужен в расчете на долговременную
> перспективу, то порядок действий хорошо известен и описан на сайте
> Unicode. Составляется заявка, подтверждающая существование искомого
> символа, посылается в UTC с таким расчетом, чтобы успеть к ближайшему
> заседанию комитета... На всю процедуру уходит около трех лет, причем
> совершенно не важно, частное ли ты лицо, или организация типа SIL.

Благодарю за информацию. Все равны, но некоторые всегда будут ровнее. :-) Ведь в Unicode столько очевидных перекосов в сторону либо влияния, либо активной поддержки (APL, dingbats, ...) 

> > Слово "неудобно" не совсем то, что имелось в виду. Мне кажется, что
> > подход, сформулированный в предложении из прошлого сообщения
> > теоретически более оптимальный (см. ниже), т.к. не нужно будет иметь
> > гравис "сам по себе" и гравис налагаемый. Можно будет обойтись "без
> > размножения сущностей без необходимости".
> Так Unicode и избегает их размножать. Вообще говоря, обычно кодируются
> только комбинируемые акценты. Имеющиеся варианты "сами по себе"
> существуют в основном только ради совместимости со старыми стандартами,
> типа той же Adobe Standard.

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

> > Но если не нырять безжизненные глубины схоластического мудрствовавния
> > (извините за выражение), то очевидно, что принадлежность буквы языку
> > определяется во многих случаях только контекстом. Сами наверное не
> > раз сталкивались с проблеммой буквы "c" на клавиатуре? В идеале, при
> > поиске эти буквы не должны различаться как и в типографском тексте.
> Опыт показывает, что на контекст зачастую полагаться нельзя.
> Вспоминается рекламное объявление эпохи перестройки, в котором
> предлагалось купить компьютеры "один-вэ-эм эр-эс а-тэ".

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

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

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

> > > глиф, а не символ.
> >
> > Но глиф - это частный случай символа.
> Глиф -- воплощение идеи символа, но сам по себе он не символ.

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

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

Композит предлагает идеальное с визуальной точки зрения решение -- никакой самый идеальный алгоритм не даст идеала в 100% случаях. Конечно, с некоторыми диакритиками (например, знаком ударения) можно работать и отдельно, но если опираться на РЕАЛЬНО ИСПОЛЬЗУЕМЫЕ знаки, а не фантазировать о ВОЗМОЖНЫХ знаках, то 32 бит должно хватить надолго, а 64 бита хватит навсегда. Понятно, что нарисовать все композиты сложно, но сделать все символы для конкретного алфавита (даже с ударениями) -- задача вполне посильная и давно решенная в типографском деле. Понятно, что создать (для книги рекордов) общий шрифт со ВСЕМИ символами будет уже нереально. Хотя, если использовать что-то типа виртуальных шрифтов ТеХ...  

> > IMHO вторичный недостаток Unicode в выделении неравноправных зон: 1)
> > 7 бит (ASCII); 2) 8 бит (ISO 8859-1); 3) 11 бит и т.д.
> Зоны 7 и 8 бит обеспечивают обратную совместимость со старыми
> стандартами, но это совсем не означает их привилегированного положения
> в рамках самого Unicode. Про 11 бит ничего не знаю. Единственная
> реальная граница -- между BMP и SMP, и она обусловлена потребностью
> в экономии места (всё же хранение текстов в 32-битном юникоде было бы
> чрезмерной расточительностью).

Но уже 8 бит не дают совместимости: 8859-1 замещается 8859-15. 8-11 бит -- это зона 2-байтных UTF-8 кодов. Вы сами писали об устаревшем ПО, но оно уже лет 20 как 32-разрядное и 64-разряда внядряются, хотя и медленно. И эта медленность обусловленна (IMHO) не проблемами с аппаратурой. А тексты все еще 7/8-разрядные преимущественно, кое-как начал лет 10 назад внедряться 16/20-разрядный (UTF-16) текст, но 20-разрядные коды все еще поддерживаются плохо. Какое-то отставание в этом направлении. А насчет расточительности, то получается, что сегодня работа с текстом напоминает собирание кораблика в бутылке. Когда многие смотрят tv или говорят как по телефону через цифровые сети, когда на DVD дисках для заполнения места цифруют звуки (80 кгц), которые могут услышать, например, летучие мыши, но не люди, и т.п. трудно говорить о расточительности. Сравните объем текстовых данных на любом компьютере с объемом прочих данных! 

> > Это все решается множествами эквивалентности для поиска и нет тут
> > никакой особой головной боли, если реализовать соответствующую
> > библиотеку поддержки. 
> Иными словами, вместо единого универсального алгоритма разбора текста
> перед поиском Вы предлагаете использовать длинные списки исключений.
> Боюсь, такое решение не нашло бы понимания среди программистов.

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

> > Зачем вытеснили КОИ-8 с PC и наплодили на
> > смех всему миру коллекцию кодировок для кириллицы? Кому-то было
> > страшно желательно иметь алфавитный порядок! 
> Ущербность КОИ-8 вовсе не в расположении по порядку латинского алфавита
> (с ним можно было бы смириться), а прежде всего в инверсии регистров,
> которая слишком явно противоречила логике всех существующих кодировок
> серий ISO-8859 и windows-125*. Плюс еще такие очевидные недостатки,
> как отсутствие типографских знаков препинания и символов славянских
> алфавитов, кроме русского.

Посмотрите на регистры в Unicode. Где там логика? Есть еще использовавшаяся с OS/2 cp855. Кстати, в кои-8 с регистрами все также как и, например, в cp1251 или iso 8859-5. Порядок символов в таблицах совершенно неважен, важно только их наличие. Как обрабатывать символы и, в частности, различать регистры, -- это информация другого порядка. А отсутствие знаков других языков... Как много русскоговорящих людей в документах на русском нуждается в сербских буквах? И даже то микроскопическое количество скорее в этом случае будет работать в среде с прямой поддержкой сербского языка. И эта проблема легко могла быть решена, как это сделали с koi8-u. Там ведь осталось много почти свободных (псевдографика, математика) позиций.

> > Хотя порядок 
> > определяется отдельными таблицами для сортировки. Создатели Unicode
> > наступили на те же грабли. Ну, зачем, изначально разбивать коды на
> > группы, добавлять к ним затем подгруппы (suppliment, extended-A,
> > ...), стремясь к строгой последовательности номеров в каждой группе?!
> <skip/>
> > Чем было
> > бы плохо иметь одну СВОДНУЮ таблицу для всей латиницы, одну для
> > греческого и т.д.? 
> Боюсь, Вы сами себе противоречите. Только что ведь говорили, что
> алфавитный порядок расположения не важен (на этом же настаивает
> и Unicode), и тут же требуете единую таблицу для каждого алфавита.

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

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

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

> > 3нaю случаи, когда группы пользователей не могут 
> > зафиксировать свои символы кроме как в зоне локальных знаков, т.е.
> > более чем ущербным способом.
> Либо не пытались, либо речь идет о каком-либо мусоре, типа Klingon.

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

> > Но это не естественные кодировки шрифта:
> Уточните всё-таки, что Вы понимаете под "естественной" кодировкой.
> А то если уж у нас даже Adobe Standard "неестественная"...
> > в шрифтах даже в пустых 
> > местах должен стоять символ типа .notdef или .null, которые тоже
> > участвуют образовании в естественной кодировки. Тут нет никой
> > проблемы, кроме терминологической.
> Если речь идет о TTF/OTF, то эти шрифты, как Вы, вероятно, знаете,
> состоят из нескольких таблиц. Так вот, не могли бы Вы пояснить, откуда
> можно взять эту самую "естественную кодировку" со всяческими .notdef
> и .null? В какой таблице она там прописана?

Давайте посмотрим на вещи практически. Загрузите fontforge или другой редактор шрифтов с любым шрифтом. То в каком порядке будут предложены символы и образует естественную кодировку. Программа ttf2afm, например, дает в такой кодирове всем глифам имена index с ПОРЯДКОВЫМ номером. А некоторая информация, в частности, о Unicode (не всегда для ttf и крайне редко для Type1) действительно хранится в отделных таблицах.

> > HTML -- весьма примитивный язык, урезанный SGML, а в самом SGML и XML
> > таких ограничений нет, там теги могут определяться обычным образом.
> Я не хотел бы сейчас обсуждать достоинства и недостатки HTML. Факт тот,
> что он является сетевым стандартом, и никакой альтернативы ему в этом
> качестве не видно. А UTF-8 разрабатывалась прежде всего именно в расчете
> на сетевое применение. Впрочем, она оказалась удобной и для других
> случаев, когда текст на естественном языке сочетается с программным
> кодом или командами разметки. В конце концов, тот же TeX может служить
> неплохим примером.
> > Да и в www и даже в РФ UTF-8 совсем не доминирует.
> Какое отношение данный факт имеет к тому, что UTF-8 наиболее удобна
> для сетевого представления _юникодовых_ документов?

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