22.07.08, 18:15, "Alexey Kryukov" <CyrTeX-ru@vsu.ru>:

> > Но откуда fontinst берет кодировку? Из сделанных мануально
> > etx-файлов! AFMtoENC может помочь такой файл получить.
> Ну так etx-файлы-то поставляются вместе с пакетом, их не надо писать
> заново. В случае с afmtoenc Вы вместо них, как я понимаю, используете
> готовые таблицы кодировок, прошитые в программу. Так в чем же
> принципиальная разница?

Да в том, что заранее всеми etx-файлами не запасешься и разбираться в них - это не так уж и просто, особенно поначалу. И нет еще, например, в стандартном пакете поддержки кириллицы t2 для fontinst некоторых схем именования кириллических глиф. Там есть только на основе имен, начинающихся с afii, а всего таких схем не менее 3-4. Кроме того, нет еще T2D. Есть подобные проблемы и для шрифтов на основе латиницы и др. И всегда было два способа установки шрифтов: 1) fontinst; 2) через утилиты vptovf, afm2tfm, ... Во-втором случае не было средств для создания файла с кодировкой, а afmtoenc -- это первое такое средство почему-то. Есть еще разница, afmtoenc позволяет делать замены, заменять похожие символы с разными уникодами, например, вместо "кириллической палочки" использовать I. Кстати, работа afmtoenc через Unicode -- это ее некоторый недостаток по-сравнению с fontinst, с Unicode напрямую не связанным, -- с символами не из UCS получается некоторая "некрасивость" -- приходиться "изобретать" уникоды из "локальных" позиций. И главное в том, что, используя текущую версию fontinst или 2-й способ, произвольный шрифт под кириллицу и не только без ручной работы с etx или enc файлом не установить.

> > Если у вас есть видение
> > кодировки, лучшей чем T2A, то не так и сложно зарегистрировать ее на
> > CTAN.
> Пробовал когда-то, но не хочу больше, надоело. Ну, будет еще одна
> экзотическая кодировка наравне со всякими cp1251-light, которую я буду
> вынужден пиарить по форумам, потому что без меня о ней никто не узнает.

Что вам мешает подключить свою кодировку к T2. TUG и CTAN вроде бы никогда не отличались бюрократизмом. И использовать, как минимум, в своих документах?

> А Unicode уже тем хорош, что и без моих усилий проживет.

Но влиять на него сложно. Более того, осмелюсь предположить, что и существование XeTeX и ваши усилия...

> > Например, не все символы из T2B, X2, LGR и др. есть в Unicode.
> В LGR таких символов нет, если не считать одной сомнительной
> вариантной формы. В X2 после принятия Unicode 5.1 осталось 4-5

Очень интересно! Чем из Unicode заполнить, например, позиции LGR c 2 по 7?

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

Но различают! А afmtoenc может замещать, когда нужно.

> к кириллическим буквам, а T2*/X2 -- видимо, нет. Это, кстати, лишний
> аргумент в пользу того, чтобы во избежание подобных непоняток
> предпочесть Unicode как более распространенный стандарт. А добавить

Однако, пользователи ТеХ тем отличались всегда, что были несколько выше текущих стандартов. ;-)

> туда еще несколько букв всегда можно, буде они действительно кому-то
> понадобятся.

Хорошо, мне понадобилась буква - как мне ее по-быстрому зафиксировать в Unicode? Это влительные организации вроде SIL могут позволить иногда из своих внутренних сиюминутных интересов (например, из-за того, что сотрудников выучили так, а переучивать - дорого, или, из-за "активистов") что-угодно пролоббировать.

> > Однако
> > разделение символов на функционирующие по-разному категории...

> Объясните, почему лично для Вас такое разделение неудобно.

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

> > Можно
> > ведь было ввести управляющий код "наложить со следующим" и думать не

> > Ведь даже неграмотному человеку очевидно,
> > что буква A одинакова и в греческом, и в румынском, и в болгарском.

> Простите, это совершенно неочевидно. Например, в терминальных шрифтах
> 80-х годов, о которых лично я вспоминаю с ностальгией, кириллическое
> заглавное "А" специально делалось так, чтобы отличаться от латинского.

Неужели настолько, что будучи поставленной в английский текст, эта буква сделает его нечитабельным?

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

Но если не нырять безжизненные глубины схоластического мудрствовавния (извините за выражение), то очевидно, что принадлежность буквы языку определяется во многих случаях только контекстом. Сами наверное не раз сталкивались с проблеммой буквы "c" на клавиатуре? В идеале, при поиске эти буквы не должны различаться как и в типографском тексте. И если с 8-битными кодами все это реализовать (использовать теорию множеств при работе с символами) было почти невоможно, то с 32-разрядными кодами это вполне реально. ИМХО проще начать разработку нового стандарта, чем пытаться приспособить  Unicode под работу с множествами. Все современные форматы текстовых документов позволяют задавать границы языковых контекстов. Неужели ВЫ считаете современные технологии работы с текстом совершенными?

> > А вы попробуйте понаблюдать за каналом ошибок ttf2afm при работе с
> > разными ttf-шрифтами (c otf все будет аналогично) -- на один символ
> глиф, а не символ.

Но глиф - это частный случай символа.

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

А как же быть с поиском?

> > Если скрещивать все со всем, то так, но не все скрещевается. :-)
> В том-то и дело, что нельзя заранее предсказать, что с чем скрещивается.
> Скажем, количество греческих акцентов вырастет в несколько раз, если
> учесть все возможные наложения со знаками долготы и краткости.

Не согласен. IMHO любой каталог должен учитывать имеющиеся употребления (например, хоть одной публикацией), а все эти разговоры о налагаемых уникодах -- это только прекрытие факта нежелания помещать многие знаки за пределы 16-разрядной зоны, а также элементарной неаккуратности ("ну может быть такой знак и все!" - и что мешает его найти, если это так, или это для науки законы, не требующие проверки?). Чья-то недалекая политика и отсталость ПО. Налагаемые знаки удобны для ввода, как в ТеХ, но (IMHO) не внутреннего предствления во многих случаях. Возможно для иностранцев при работе с русскими текстами будет удобнее вводить "й" или "ё" через диакритики, но внутреннее представление этих символов не должно содержать этих дикритик. А вот "ё" и "е" при поиске можно не различать, если искать "е". И в каждом языке свои особенности, которые простыми схемами не опишешь. В некоторых случаях явное использование диакритик может быть полезным (ударения, например). IMHO вторичный недостаток Unicode в выделении неравноправных зон: 1) 7 бит (ASCII); 2) 8 бит (ISO 8859-1); 3) 11 бит и т.д.

> > расширить Unicode до 2^64. IMHO накладываемые диакритики в Unicode --
> > это ошибка.
> Напротив, это очень удобно. Дело в том, что декомпозиция акцентированных
> символов нужна всё равно хотя бы для реализации алгоритмов поиска
> (искать текст с акцентами очень неудобно). А если есть декомпозиция,
> то каждый готовый композит добавляет головной боли разработчикам
> шрифтов (нужно ведь, чтобы оба представления символа выглядели
> идентично).

Это все решается множествами эквивалентности для поиска и нет тут никакой особой головной боли, если реализовать соответствующую библиотеку поддержки. Уже не раз частностями создавались принципиальные проблемы. Зачем вытеснили КОИ-8 с PC и наплодили на смех всему миру коллекцию кодировок для кириллицы? Кому-то было страшно желательно иметь алфавитный порядок! Хотя порядок определяется отдельными таблицами для сортировки. Создатели Unicode наступили на те же грабли. Ну, зачем, изначально разбивать коды на группы, добавлять к ним затем подгруппы (suppliment, extended-A, ...), стремясь к строгой последовательности номеров в каждой группе?! Если иметь общий каталог, то что мешает затем проводить его систематизацию, а не заниматься пустопорожним поиском подходящего места для символа или группы в более привелигированной зоне? Это позволило бы поставить регистрацию новых символов "на поток" да и дало бы работы разным систематизаторам, вместо навязывания им схем, придуманных во многих случаях разработчиками системного ПО. Чем было бы плохо иметь одну СВОДНУЮ таблицу для всей латиницы, одну для греческого и т.д.? 3нaю случаи, когда группы пользователей не могут зафиксировать свои символы кроме как в зоне локальных знаков, т.е. более чем ущербным способом.

> > Но Unicode должен "освящать" символы либо утвержденные редкими
> > древними документами (хотя тут много вопросов), либо частотой
> > использования. А пытаться уследить за всеми возможными взрывами
> > фантазии - это явная утопия.
> Вот то-то и оно, что много вопросов. А как быть с орфографиями и
> фонетическими системами, которые когда-то принимались в качестве
> нормативных, но ныне забыты? На мой взгляд, именно здесь лежит
> основной источник проблемных символов. Между прочим, многие буковки
> из T2*/X2 -- именно этого сорта.

Если иметь равноправие кодов, то в силу их количества, эта проблема снимается сама-собой. Все как на google mail: зачем уничтожать, когда можно архивировать?! Mеста достаточно!

> Хорошо, ответьте тогда: лично _Вы_ учитываете кодировку tipa
> в afmtoenc? Если да, то как Вы решаете обсуждаемую ниже проблему
> с позиционированием глифа в ячейке?

Нет, сложновато это... TS1, T3, TS3 и нек. др. - тоже не поддерживаются. :-( Хотя и целей таких глобальных не ставилось. Нужно было попробывать несколько ttf-шрифтов и утилитка появилась сама собой за несколько часов, потом уже появилось желание несколько ее усовершенствовать. Сложности напрямую связаны с отсутсвием информации о связи упомянутых таблиц и Unicode. :-(
 
> > А весь Unicode, пока он развивается, это некая
> > нереализуемая вполне универсалия с множеством разрывов в кодах. Из-за
> > последнего кодировка Unicode никак не может быть естественной,
> > определяемой порядком.

> Подумаешь, проблема. Многие восьмибитные кодировки содержат пустые места
> (Adobe Standard вообще наполовину состоит из них). Это же не мешает
> программам их обрабатывать.

Но это не естественные кодировки шрифта: в шрифтах даже в пустых местах должен стоять символ типа .notdef или .null, которые тоже участвуют образовании в естественной кодировки. Тут нет никой проблемы, кроме терминологической.

> Объяснил же я, что _одной_ таблицы на _один_ язык во многих
> случаях не хватает.

Любопытно было бы узнать про какой-нибудь содержательный пример. Вы писали про греческий и арабский. Значит ли это, что при наборе греческих или эмиратскмх газет используются более 256 локальных символов?

> > В UTF-8 есть "основные" символы ASCII, с которыми работают как с
> > обычными ASCII, и прочие малонужные среднему англоговорящему
> > пользователю "добавки". И эти "основные знаки" вполне помещаются в 8
> > бит. Если бы это было бы не так, то нужды в UTF-7/8/16 совсем бы не
> > было.
> Причина совершенно иная. Символы ASCII действительно являются основными,
> но не для естественных, а для машинных языков, к каковым, в частности,
> относится HTML. И вот именно за счет тегов HTML и прочей разметки (а
> они зачастую занимают 90% общего объема страницы) получается
> существенная экономия WWW-трафика независимо от языка передаваемого
> содержимого. Если же реализовать Вашу идею кириллического (или
> греческого) UTF-8, то это не только не дало бы никакой экономии, но
> и разбило бы интернет на несовместимые сегменты из-за различного
> представления тех самых тегов.

HTML -- весьма примитивный язык, урезанный SGML, а в самом SGML и XML таких ограничений нет, там теги могут определяться обычным образом. Да и в www и даже в РФ UTF-8 совсем не доминирует. Локальные особенности учитываются все больше и больше, их иногда почти что навязывают. Например, для работавших с Visual Basic существует постоянный "кошмар" (программы перестают работать с новыми версиями VBA!) медленной русификации. Сначала точку в числах заменили на запятую, потом названия функций стали русифицировать и т.п. Могу даже сформулировать предположение, XeTeX может стать доминирующим, если большинство сайтов www РФ, Европы и Америки перейдет с 8-битных кодировок на Unicode. ;-)