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: Mon, 25 Aug 2008 15:21:07 +0400
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <list-101518550@relay1.vsu.ru> <list-110043470@relay1.vsu.ru> <list-111193320@relay1.vsu.ru>
In-Reply-To: <list-111193320@relay1.vsu.ru>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="koi8-r"
Content-Transfer-Encoding: 8bit
Message-Id: <200808251521.07431.anagnost@yandex.ru>

On Thursday 21 August 2008, Лидовский Владимир wrote:
>
> Конечно, именно об этом дополнении и была речь. А в упомянутом файле
> действительно прописаны некоторые соответствия для Type 1 шрифтов,
> сделанных весьма давно. Если вы найдете хоть один ttf-шрифт со
> схемами именования из этого файла, то это будет чем-то почти
> невероятным. Схем, используемых в ttf-шрифтах, там нет. :-(

А какие схемы используются в TTF-шрифтах помимо стандартной,
основанной на AGL? Приведите примеры, пожалуйста.

> А вы ни в чем не запутались? T1, T2* и нек. др. используются через
> пакет fontenc, а inputenc - это только для удобства ввода. 

Попутал, конечно. Имел в виду именно fontenc.

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

Имена семейств там нужны только для команды \DeclareEncodingSubset
(признаться, я и не знал о ее существовании). Но ведь она нужна только
для того, чтобы гарантировать корректное отображение некоторых редко
используемых символов. В большинстве случаев без нее прекрасно можно
обойтись, а значит, и согласований никаких не надо.

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

Опять же, тут одно из двух: либо глиф доступен через механизм OpenType
(как маленькие заглавные или минускульные цифры), либо он сам по себе
никому не нужен, а традиционно поддерживался только в качестве
компонента для построения других глифов. Это как раз относится к
заглавным акцентам.

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

Петр Овченков здесь неоднократно высказывался против поддержки T2D
в cyrillic bundle (можете поднять на эту тему архивы рассылки). Думаю,
с тех пор ничего не изменилось.

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

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

> Как Вы, например, введете эти два знака в XeTeX?

Дигамму (строчную или заглавную) введу, набрав символы Unicode с
соответствующими кодами (U+03DC/U+03DD). А если мне понадобится 
особая-красивая-дигамма, то возьму шрифт, в котором такая форма
используется по умолчанию либо доступна через механизм подстановок.
Потому что никакой особой семантики по сравнению со стандартной
дигаммой у этой буковки, судя по всему, нет, а значит -- это именно
глиф, а не символ.

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

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

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

Скажу, что это именно символы с совершенно разной семантикой.
Разумеется, речь идет только об использовании в математическом
контексте, на которое данный блок и ориентирован.

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

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

> Неужели вы осмелитесь утверждать, что в уникодах 
> "тильда сверху", "посередине" и "снизу" сам знак "тильда" выглядит
> по-разному? 

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

> Попробуйте,
> посмотрите на проблему непредвзято и увидите, что у знаков кроме
> сходства-несходства объективно больше ничего нет, а все остальное
> определяется контекстом и схоластическим "теоретизированием".

Этот подход работал бы, если бы дело ограничивалось сходством некоторых
разных по значению символов. Но ведь бывает и так, что один и тот же
символ пишется совершенно по-разному. Сравните, например, "Л домиком"
и "Л-трапециевидное". Предлагаете отождествить его с Ламбдой на основе
сходства первой формы? Или вот русское "т" и латинское "m": казалось
бы, никакого внешнего сходства, однако же рукописное начертание
совпадает. Так что, отождествлять их или нет?

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

Не согласен. От того, что мы вставляем в свою речь латинскую
аббревиатуру (тем более такую известную), мы не начинаем говорить
по-английски. Бессмысленность переключения на другой язык в данной
ситуации становится особенно очевидной, если мы представим ту же
аббревиатуру в контексте языка, отличного от английского, но
использующего латинский алфавит. Должны ли немцы и поляки переключаться
на английский язык всякий раз, как им захочется написать "PC"?

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

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

идея (эйдос) человека : человек по имени Сократ == символ : глиф

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

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

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

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

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

> > уже закодированных символов зафиксированы и не подлежат изменению.
>
> Но вы писали о появлении каких-то новых свойств, неужели не символов?

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

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

Единообразие кодировок в свое время очень облегчало жизнь разработчикам
ПО. Тут и преобразование регистров, и то обстоятельство, что, скажем,
значки, используемые для индикации непечатаемых символов, всюду
находились на одних и тех же местах. Или вот типографские кавычки:
алгоритм smart quotes тоже мог работать независимо от локализации
системы и отдельного приложения. Также не надо недооценивать и
эстетический момент: с логично организованной таблицей просто удобнее
работать. Конечно, в Unicode это уже не получается, но ведь 8-битные
кодировки -- совсем иное дело: там количество символов ограничено, и
вполне можно было продумать логику их расположения заранее.

А что от этого пришлось отказаться -- ну так ничего не поделаешь,
жизнь не стоит на месте. Когда-нибудь и Unicode изживет себя.

> Упоминалась еще cp855 с совершенно 
> необычной логикой расположения знаков кириллицы.

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

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

Умляуты как раз укладывались в общую логику: диапазон c0-df для
заглавных, e0-ff для строчных. Впрочем, кое-что приходилось ставить
и в другие позиции, но и тогда, однажды поместив в какие-либо два слота
одну регистровую пару, старались не отступать от этого правила и в
других кодировках серии.

Что до буквы "ё", то koi8-r в базовом варианте еЁ вообще не включала.
Так что и тут она в пролете.

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

Не проблема, но зачем множить сущности без необходимости? Ведь одной 
cp1251 вполне хватало для всех живых славянских языков. А пользователи
koi почему-то продолжали держаться за ненужную псевдографику. Да что
там, неужели нельзя было хотя бы принять koi8-u в качестве общей
кодировки для России и Украины?

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

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

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

Ну есть такие множества атрибутов, да и выборку сделать, наверное,
не проблема. Хотя если Вам нужно, чтобы для каждого символа прямо
в стандарте перечислялись все языки, в которых он используется, то
это просто-напросто нереально. Еще ведь никому не удалось точно
сказать, сколько всего на свете языков. А существуют еще разные
системы транслитерации, многие из которых устарели или были выдуманы
кем-то лично для себя. Их тоже считать за языки?

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

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

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

Абсолютно недостаточен: никто же не знает, из каких соображений его
туда поместили. Вот, например, такой монстр, как inverted interrobang,
который, правда, в итоге приняли в Unicode, хотя и с большим скрипом.
Заведомо известно, что этот символ никогда никем не применялся. А
закодировали его из тех соображений, что, мол, если уж американские
типографы придумали interrobang (тоже уродище еще то), то, наверное,
среди многочисленных испаноязычных американцев найдутся и такие, которые
захотят применять его в паре с перевернутым аналогом.

> Места-то полно!

Что толку кодировать символ, если его никто не будет поддерживать? Ведь
по Вашей же теории каждый дизайнер должен делать только то, что лично
ему, дизайнеру, надо. А надо ему эти странные значки из TS1, которые
он никогда и в документах-то не видел?

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

В шрифтах, не разрабатывавшихся специально для TeX, почти наверняка нет
как раз perthousandzero. А вот знак промилле точно есть, благо он входит
в cp1252 и cp1251.

> Ведь символа perhundredthousand нет, а этот знак проблему решает.

А такой символ реально существует и применяется? Или это такой же
искусственный конструкт, как и inverted interrobang?

> А никто и не утверждал его особенной полезности. 

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

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

Вот не пойму, как может AFMtoENC использовать эту кодировку? Она же
не с TTF напрямую работает, а с AFM. А в AFM, которые получаются
после ttf2afm, кодировки вообще никакой нет, только имена глифов.

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

Эти данные формируются непосредственно при генерации PDF, а не
берутся из шрифта.

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

Здесь нестыковка в понимании терминов. С Вашей точки зрения, таблица
есть просто некая матрица. В спецификации же TTF под таблицей понимается
фрагмент структуры двоичного файла, отвечающий определенным требованиям.
Существенно, что смещение каждой таблицы указано в заголовке файла,
так что к ней можно осуществлять доступ независимо от остального
содержимого. А что там за данные содержатся, определяется той же
спецификацией отдельно для каждого вида таблиц. Вполне может быть
и массив скаляров.

В Type 1 таких таблиц нет, как нет и возможности обращаться к частям
файла по отдельности.

> положение в ИТ, то как вы объясните грузинам, почему их язык на менее
> почетном месте, чем армянский? Похоже мы начинаем повторяться, но
> разве все написанное в этом абзаце неочевидно? 

Не пойму я Вас. То Вы настаиваете на освоении безбрежных пространств
32-битного Юникода, мотивируя это тем, что при современном железе
обработка удвоенного объема данных проблемы не составит, а то вдруг
поднимаете шум из-за лишнего байта, которого требует кодирование
грузинских букв, рискуя спровоцировать новую войну на Кавказе :)
Да какая вообще разница, сколько байтов на какой символ уходит,
если в целом файлы получаются вполне приемлемого объема?

> Более того, могу 
> сейчас опровергнуть ваше утверждение, что для html необходим ASCII и
> поэтому существующему UTF-8 нет альтернативы: в html можно
> использовать, например, UTF-16

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

> и ЛЮБУЮ другую стандартную кодировку.

А при использовании "любой другой стандартной кодировки" теги будут
в ASCII или в чем другом?

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

Moscow State University
Historical Faculty