From: "=?KOI8-R?B?7MnEz9fTy8nKIPfMwcTJzcnS?=" <CyrTeX-ru@vsu.ru>
Received-SPF: pass
 receiver=relay1.vsu.ru; client-ip=77.88.60.20; envelope-from=litwr@yandex.ru
To: cyrtex-ru@vsu.ru
In-Reply-To: <list-111925560@relay1.vsu.ru>
References: <list-101518550@relay1.vsu.ru> <list-110043470@relay1.vsu.ru> <list-111193320@relay1.vsu.ru> <list-111925560@relay1.vsu.ru>
Subject: Re: Unicode, AFMtoENC
MIME-Version: 1.0
Message-Id: <185011219906093@webmail41.yandex.ru>
Date: Thu, 28 Aug 2008 10:48:13 +0400
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=KOI8-R

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

Приходиться в кое-чем повторяться. :-( В дистрибутиве Linux, который использую, есть ряд ttf-шрифтов, в которых Б называется uni0411 (CharisSIL) или Becyrillic (Lucida). Не стал искать другие конкретные примеры, но встречал такие схемы именования в ДЕСЯТКАХ ttf-шрифтов.

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

Eсть в TS1, которая появилась не по "иванушкиному велению", например, знак листка. И говорить, что этот и ряд других САМОСТОЯТЕЛЬНЫХ символов никому не нужен, это как-то уж очень неуважительно и пахнет дурным волюнтаризмом.

> компонента для построения других глифов. Это как раз относится к
> заглавным акцентам.

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

IMHO само присутствие еще одной кодировки никому бы не помешало, если все правильно оформить на уровне кодов и гарантировать поддержку. С другой стороны, можно все подготовить отдельным пакетом, т.е. несколько расширить поддержку того, что есть. И чего бы вы конкретно хотели добиться, переносов c йотированной а? 

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

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

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

Это касается любой кодировки. Как вы из Unicode достанете отсутствующий там знак?

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

Ну вот и вы заговорили о влиянии контекста, разметки! А ведь далее утверждаете о самодостаточности Unicode. Иногда автору может быть желательно сохранить вариантность формы при копировании, например. Другое дело, что эти символы или глифы должны не различаться при поиске. Ведь речь не идет о стандартных, общих вариациях типа курсива. И потом, разметка по имени шрифта, - низкоуровневая и, следовательно, несколько архаичная.

> > Боятся с ним связываться - обычное дело. Ждут возможно, что этот
> > мутный стандарт заменят на что-то более демократичное. 

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

Война авторитов... Возможно TLG почти права, но существование LGR показывает, что не на все 100.

> > А что вы скажите об уникодах в диапазоне 1d400-1d7ff? 

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

КОНТЕКСТ! Вот и я все время об этом. Зачем специальный уникод, когда вид определится КОНТЕКСТОМ. Запуталиcь в Unicode окончательно. :-(

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

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

> кодов, максимум видимых символов. Кстати, в этом формате нет и языковой

Накладываемые диакритики -- это и контрольные коды тоже, их и можно в несколько раз уменьшить в количестве.

> разметки, что опять-таки не позволяет реализовать многие из Ваших идей.

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

Да, можно заглавные/строчные буквы рассматриваить как стандартные вариации, но Unicode и тут не до конца последователен.

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

Какая чепуха! Ну нет никакой прямой связи между вводом и внутренним представлением. Как вы сейчас вводите, где вам нравится, так же и при другом внутреннем представлении будете вводить - какая тут проблема?! Проблема в бессмысленности раздувания таблиц и порочном смешивании "мух и котлет". Примеры, нажатие Enter производит в Linux один код, а Microsoft Windows - 2. Ввод Ё в LaTeX напрямую или с \" приводит к одинаковым результатам при переходе к dvi/pdf.

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

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

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

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

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

> Не согласен. От того, что мы вставляем в свою речь латинскую
> аббревиатуру (тем более такую известную), мы не начинаем говорить
> по-английски. Бессмысленность переключения на другой язык в данной

Именно начинаем, иначе нужно признать, что эта аббревиатура входит в русский язык, что невозможно хотя бы из-за отсутствия в алфавите русского языка буквы I. Посмотрите старые книги 70-х, даже 80-х - там почти не было иноязычных аббревиатур: ЭВМ, ЦАП, ОЗУ, ИБМ, ПК,  АЦПУ, ... Вы спорите с более, чем очевидными вещами.

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

Там такие фразы могут из-за сходства алфавитов рассмотриваться как фразы-исключения в соответствующих языках (в английском немало слов почти прямо перенесенных из французкого и т.п.), но речь может идти только о каких-то очень широко используемых выражениях, включенных в язык фиксацией в словарях, хотя когда говорят, например, c'est la vie - это порождает французкий конткекст, а ciao - итальянский, и качественная разметка должна это отражать, что будет полезно и для проверки провописания. 

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

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

"Человек" как понятие - всегда универсалия, а "конкретный человек" возникает лишь при дополнительных указаниях и вообще через универсалии (какими являются слова) вполне не определяется.

> для того, чтобы такой путаницы не возникало. Если угодно, правильное
> соотношение понятий можно изобразить так:
> идея (эйдос) человека : человек по имени Сократ == символ : глиф

Надеюсь, что до спора номиналистов и реалистов, который тянулся сотни лет, дела не дойдет. ;-) Он ведь так и не был закончен, как и сказка про белого бычка. :-) Позволю себе пока, несмотря на ваши возражения считать Сократа человеком, а глиф символом. А чтобы наш "белый бычок" не ушел слишком далеко, Вам возможно стоит дать мне ссылку на материалы с четкими определениями, где бы доказывалось обратное.

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

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

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

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

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

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

Вы смотрите на проблему глазами разработчиков шрифтов, которые хотят сделать побольше глиф меньшими усилиями - построить свою маленькую вавилонскую башню. В любом естественном языке с алфавитной письменностью общее количество знаков весьма невелико, включая те, что с диакритиками. Большинство сложностей возникает при попытке создавать шрифты с символами, используемыми в редких, узкоспециальных целях. Обычные, широкоиспользуемые символы с диакритиками имеют отдельные уникоды. Накладываемые диакритики - это, конечно, весьма удобный, но ДОПОЛНИТЕЛЬНЫЙ инструмент для РЕДКИХ случаев. Шрифт, в котором Й и Ё будут получаться наложением с диакритиками, всегда будет считаться не слишком качественным. Во многих типографских шрифтах Е под двумя точками не такое же как Е само по себе, это же верно и для Й...

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

Не понимаю, о чем вы. Посмотрите, на почтеннейшую cp437 (cp850, ...) - где там возможность, не используя таблиц, единым способом преобразовывать регистры? Такая возможность есть, наверное, только в iso-8859-1, да и там есть исключения.

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

Где вы видели логично организованные таблицы?! Назовите хоть одну. Упомянутая 8859-1 наверное самая логичная.

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

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

Это вы, похоже, об iso-8859-1, об очень редком исключении. А вот уже в кириллической 8859-5 логика для Ё или букв нерусских алфавитов особенная.

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

В koi8-r, стандартизированной в internet'e в 1993, Ё была изначально. В ее предшественнице КОИ-8 ЁёЪ действительно не было, но проще было их туда добавить еще в 80-е, а не плодить море кодировок из-за второстепенных надуманных требований.

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

> Навязывание существует только в Вашем воображении. Повторяю, многие

Где альтернатива?

> лица, связанные с UTC, неоднократно заявляли (практически Вашими
> словами) о неважности места символа в кодировке. Но если группа

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

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

!!!

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

И где на них можно посмотреть?

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

Ну зачем же все и сразу? То о чем забыли, можно ведь отметить и потом.

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

Если были публикации, то почему бы нет? Места-то на всех хватит! Отвергать символ, который был хотя бы в одной публикации для единой таблицы кодов несколько противоестественно. В нормальном стандарте таблицы бы сами пополнялись на основе публикаций без участия авторов и заявок.

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

Я вам просто и искенне завидую. Мне уж года 3-4 с Unicode душно, а от его некоторых надуманных схем еще хуже. :-(

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

Эту простейшую БД можно было бы выложить в текстовом sql-варианте и обеспечить онлайн-доступ к СУБД. Тут нет ничего такого, что потребовало бы, каких-то специализированных и возможно небесплатных программ. Хотя какие-то дополнительные сервисы могли бы быть и небесплатными.

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

> Абсолютно недостаточен: никто же не знает, из каких соображений его
> туда поместили. Вот, например, такой монстр, как inverted interrobang,

Ну приняли же! А чем символ из кодировки ТеХ хуже?

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

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

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

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

Если вы такой знак поставите, то все, кто знает о знаке промилле, поймут его значение. Что еще надо? Или удивлены тем, что создатели T1 оказались дальновиднее ВЕЛИКОГО и БEЗУПРЕЧНОГО Unicode?

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

Hе Unicode критиковался, а то, что Unicode, будучи опциональным прикреплением, определяет порядок глиф в шрифте.

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

Строго говоря, вы правы, - в afm порядок может быть любым, но порядок в afm-файлах, полученных, например, ttf2afm, соответствует естественной кодировке: у каждого имени есть свой порядковый номер.

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

Tак происходит с pdfTeX при использовании долгое время недокументированной команды \pdffontattr. Но теоретически такая информация может вероятно добавляться напрямую к Type 1 шрифту. Ведь команды cmap-файлов - это PostScript, не PDF.

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

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