|
|
On Friday 25 July 2008, Лидовский Владимир wrote:
> них - это не так уж и просто, особенно поначалу. И нет еще, например,
> в стандартном пакете поддержки кириллицы t2 для fontinst некоторых
> схем именования кириллических глиф. Там есть только на основе имен,
> начинающихся с afii, а всего таких схем не менее 3-4.
Это не так. Там именно поддерживаются (через механизм alias) несколько
различных схем именования. Впрочем, едва ли это так важно: признаться,
не припомню ни одного шрифта с нестандартными именами глифов, который
стоил бы трудов по прикрутке к TeX.
> Кроме того, нет еще T2D.
А у Вас, как выяснилось, нет TS1, которая гораздо важнее.
> Что вам мешает подключить свою кодировку к T2. TUG и CTAN вроде бы
> никогда не отличались бюрократизмом. И использовать, как минимум, в
> своих документах?
TUG и CTAN -- возможно. Боюсь, главное затруднение возникло бы не там,
а при попытке пропихнуть кодировку в Бабель и cyrillic bundle (напомню,
что там до сих пор нет T2D, хотя при всех своих недостатках она уж
точно не хуже какой-нибудь X2). К счастью, мне это уже не нужно.
> Очень интересно! Чем из Unicode заполнить, например, позиции LGR c 2
> по 7?
На это Владимир уже ответил. Добавлю, что в 7-й позиции стоит та самая
сомнительная вариантная форма: символ, который называется vardigamma,
но в качестве дигаммы неузнаваем.
> Хорошо, мне понадобилась буква - как мне ее по-быстрому зафиксировать
> в Unicode?
"По-быстрому", конечно, не получится, иначе бы Юникод был куда худшей
помойкой, чем он является сейчас. Поэтому, если потребность в символе
однократная, то проще поместить его в пользовательскую область и не
париться. Но если символ действительно нужен в расчете на долговременную
перспективу, то порядок действий хорошо известен и описан на сайте
Unicode. Составляется заявка, подтверждающая существование искомого
символа, посылается в UTC с таким расчетом, чтобы успеть к ближайшему
заседанию комитета... На всю процедуру уходит около трех лет, причем
совершенно не важно, частное ли ты лицо, или организация типа SIL.
Говорю это со знанием дела, т. к. сам составлял заявку на добавление
славянских буквотитл и активно участвовал в дискуссии, которая за этим
последовала.
> Слово "неудобно" не совсем то, что имелось в виду. Мне кажется, что
> подход, сформулированный в предложении из прошлого сообщения
> теоретически более оптимальный (см. ниже), т.к. не нужно будет иметь
> гравис "сам по себе" и гравис налагаемый. Можно будет обойтись "без
> размножения сущностей без необходимости".
Так Unicode и избегает их размножать. Вообще говоря, обычно кодируются
только комбинируемые акценты. Имеющиеся варианты "сами по себе"
существуют в основном только ради совместимости со старыми стандартами,
типа той же Adobe Standard.
> Неужели настолько, что будучи поставленной в английский текст, эта
> буква сделает его нечитабельным?
Сделает чтение некомфортным, примерно так же, как латинское "K",
поставленное вместо русского "К".
> Но если не нырять безжизненные глубины схоластического мудрствовавния
> (извините за выражение), то очевидно, что принадлежность буквы языку
> определяется во многих случаях только контекстом. Сами наверное не
> раз сталкивались с проблеммой буквы "c" на клавиатуре? В идеале, при
> поиске эти буквы не должны различаться как и в типографском тексте.
Опыт показывает, что на контекст зачастую полагаться нельзя.
Вспоминается рекламное объявление эпохи перестройки, в котором
предлагалось купить компьютеры "один-вэ-эм эр-эс а-тэ".
> Все современные форматы текстовых документов позволяют задавать
> границы языковых контекстов.
Позволяют, но работает это хорошо только в том случае, если показатель
языка устанавливался вручную. Если же это делается автоматически при
переключении раскладки, то зачастую получается (в самом простом случае)
каша из русских и псевдо-английских фрагментов. Это я опять же к тому,
что автоматическое определение "контекста" до добра не доводит. Гораздо
удобнее считать, что между символами разных алфавитов нет ничего общего,
сколь бы сходными они ни казались.
> > глиф, а не символ.
>
> Но глиф - это частный случай символа.
Глиф -- воплощение идеи символа, но сам по себе он не символ.
> > И что здесь не так? Ну да, в Юникоде много внешне схожих символов.
> > Некоторые из них могут совпадать или различаться по форме в
> > зависимости от общего стиля шрифта, другие были клонированы просто
> > по ошибке (что ж, все мы люди) или из иных соображений. Поэтому
> > вполне естественно, что разработчики шрифтов иногда сопоставляют
> > нескольким символам одну и ту же картинку, физически хранящуюся в
> > шрифте. Это вопрос всего лишь удобства разработки шрифтов, а не
> > самого стандарта. Если какие-то программы принимают такую ситуацию
> > за ошибку -- что ж, это их проблемы.
>
> А как же быть с поиском?
С поиском где? Если по текстовому документу, то проблем никаких нет,
т. к. там хранятся только коды символов, а какие именно картинки из
данного шрифта берутся для их отображения -- это уже вопрос совершенно
отдельный и к алгоритму поиска отношения не имеющий. А вот с поиском
в PDF проблемы действительно возможны, т. к. юникоды символов там не
хранятся, а восстанавливаются на основании имен глифов. Поэтому двойной
кодировкой надо пользоваться с осторожностью: только для стопроцентных
дублей, или же для небуквенных символов, которые едва ли кто-то будет
задавать на поиск.
> Не согласен. IMHO любой каталог должен учитывать имеющиеся
> употребления (например, хоть одной публикацией), а все эти разговоры
> о налагаемых уникодах -- это только прекрытие факта нежелания
> помещать многие знаки за пределы 16-разрядной зоны, а также
> элементарной неаккуратности ("ну может быть такой знак и все!" - и
> что мешает его найти, если это так, или это для науки законы, не
> требующие проверки?). Чья-то недалекая политика и отсталость ПО.
С больной головы на здоровую... Согласитесь, отобразить готовый
композит гораздо проще, чем корректно позиционировать комбинируемый
акцент. Собственно, именно потребность работать с устаревшим ПО всегда
была главным аргументом в пользу композитов.
> Налагаемые знаки удобны для ввода, как в ТеХ, но (IMHO) не
> внутреннего предствления во многих случаях.
Хорошо, давайте разберемся. Дело в том, что можно выделить несколько
классов акцентированных символов. Первый случай -- это когда
символ с акцентом считается самостоятельной буквой в алфавите
какого-либо языка, совершенно отличной от своего неакцентированного
прототипа. Типичным примером здесь может служить русская буква "й".
Второй случай -- когда употребление символа обусловлено нормами
орфографии языка, но он всё же воспринимается не как самостоятельная
буква, а как акцентированный вариант другой буквы (и при сортировке по
алфавиту, соответственно, приравнивается к ней). Таковы французские
аксаны и немецкие умляуты. Такова же, по моему убеждению, буква "ё".
И, наконец, третий случай -- когда акцент добавляется в качестве
модификатора для обозначения определенного фонетического эффекта.
Например, в русском алфавите нет буквы "а ударное", хотя знак ударения
используется довольно часто.
Так вот. По-моему, достаточно очевидно, что кодирование с помощью
готового композита выглядит предпочтительным в первом случае,
оправданным -- во втором и совершенной бессмыслицей -- в третьем (именно
потому, что буква "а" с ударением всё же остается не чем иным, как
буквой "а"). Между тем именно третья группа является самой
многочисленной и хуже всего поддается нормированию и учету. Unicode
совершенно правильно сделал, что отказался от безнадежных попыток
создать полный список всех таких случаев. В то же время символы первой
и второй групп по большей части оказались учтены в стандарте, так что
с ними никакой проблемы нет.
> IMHO вторичный недостаток Unicode в выделении неравноправных зон: 1)
> 7 бит (ASCII); 2) 8 бит (ISO 8859-1); 3) 11 бит и т.д.
Зоны 7 и 8 бит обеспечивают обратную совместимость со старыми
стандартами, но это совсем не означает их привилегированного положения
в рамках самого Unicode. Про 11 бит ничего не знаю. Единственная
реальная граница -- между BMP и SMP, и она обусловлена потребностью
в экономии места (всё же хранение текстов в 32-битном юникоде было бы
чрезмерной расточительностью).
> Это все решается множествами эквивалентности для поиска и нет тут
> никакой особой головной боли, если реализовать соответствующую
> библиотеку поддержки.
Иными словами, вместо единого универсального алгоритма разбора текста
перед поиском Вы предлагаете использовать длинные списки исключений.
Боюсь, такое решение не нашло бы понимания среди программистов.
> Зачем вытеснили КОИ-8 с PC и наплодили на
> смех всему миру коллекцию кодировок для кириллицы? Кому-то было
> страшно желательно иметь алфавитный порядок!
Ущербность КОИ-8 вовсе не в расположении по порядку латинского алфавита
(с ним можно было бы смириться), а прежде всего в инверсии регистров,
которая слишком явно противоречила логике всех существующих кодировок
серий ISO-8859 и windows-125*. Плюс еще такие очевидные недостатки,
как отсутствие типографских знаков препинания и символов славянских
алфавитов, кроме русского.
> Хотя порядок
> определяется отдельными таблицами для сортировки. Создатели Unicode
> наступили на те же грабли. Ну, зачем, изначально разбивать коды на
> группы, добавлять к ним затем подгруппы (suppliment, extended-A,
> ...), стремясь к строгой последовательности номеров в каждой группе?!
<skip/>
> Чем было
> бы плохо иметь одну СВОДНУЮ таблицу для всей латиницы, одну для
> греческого и т.д.?
Боюсь, Вы сами себе противоречите. Только что ведь говорили, что
алфавитный порядок расположения не важен (на этом же настаивает
и Unicode), и тут же требуете единую таблицу для каждого алфавита.
Конечно, хорошо было бы заранее знать точное число всех когда-либо
употреблявшихся символов латиницы или кириллицы, чтобы разместить
их в таблице рядом. Но поскольку это нереально, приходится мириться
с чересполосицей блоков, которые, естественно, должны как-то
называться (иначе в них было бы слишком сложно ориентироваться).
> 3нaю случаи, когда группы пользователей не могут
> зафиксировать свои символы кроме как в зоне локальных знаков, т.е.
> более чем ущербным способом.
Либо не пытались, либо речь идет о каком-либо мусоре, типа Klingon.
> Если иметь равноправие кодов, то в силу их количества, эта проблема
> снимается сама-собой. Все как на google mail: зачем уничтожать, когда
> можно архивировать?! Mеста достаточно!
В общем-то, Unicode так и делает.
> > Хорошо, ответьте тогда: лично _Вы_ учитываете кодировку tipa
> > в afmtoenc? Если да, то как Вы решаете обсуждаемую ниже проблему
> > с позиционированием глифа в ячейке?
>
> Нет, сложновато это... TS1, T3, TS3 и нек. др. - тоже не
> поддерживаются. :-(
Ну вот видите. А между отсуствие поддержки TS1 резко ограничивает
полезность Вашей программы. Изготовление шрифтовых пакетов без
учета этой кодировки -- вообще очень плохая практика.
> Но это не естественные кодировки шрифта:
Уточните всё-таки, что Вы понимаете под "естественной" кодировкой.
А то если уж у нас даже Adobe Standard "неестественная"...
> в шрифтах даже в пустых
> местах должен стоять символ типа .notdef или .null, которые тоже
> участвуют образовании в естественной кодировки. Тут нет никой
> проблемы, кроме терминологической.
Если речь идет о TTF/OTF, то эти шрифты, как Вы, вероятно, знаете,
состоят из нескольких таблиц. Так вот, не могли бы Вы пояснить, откуда
можно взять эту самую "естественную кодировку" со всяческими .notdef
и .null? В какой таблице она там прописана?
> Любопытно было бы узнать про какой-нибудь содержательный пример. Вы
> писали про греческий и арабский. Значит ли это, что при наборе
> греческих или эмиратскмх газет используются более 256 локальных
> символов?
Видите ли, это было бы настолько неудобно, что, конечно, этого
всячески избегают. Интересны именно те ухищрения, на которые ради этой
цели приходится идти. Про греческий я уже говорил: символы в принципе
размещаются, но приходится в каких-то деталях жертвовать удобством
набора и типографским качеством. А вот создатели ArabTeX вышли из
положения только за счет того, что закодировали не сами буквы, а
отдельные компоненты, из которых эти буквы строятся.
> HTML -- весьма примитивный язык, урезанный SGML, а в самом SGML и XML
> таких ограничений нет, там теги могут определяться обычным образом.
Я не хотел бы сейчас обсуждать достоинства и недостатки HTML. Факт тот,
что он является сетевым стандартом, и никакой альтернативы ему в этом
качестве не видно. А UTF-8 разрабатывалась прежде всего именно в расчете
на сетевое применение. Впрочем, она оказалась удобной и для других
случаев, когда текст на естественном языке сочетается с программным
кодом или командами разметки. В конце концов, тот же TeX может служить
неплохим примером.
> Да и в www и даже в РФ UTF-8 совсем не доминирует.
Какое отношение данный факт имеет к тому, что UTF-8 наиболее удобна
для сетевого представления _юникодовых_ документов?
--
Regards,
Alexej Kryukov <anagnost at yandex dot ru>
Moscow State University
Historical Faculty
|
|