|
|
On Friday 18 July 2008, Лидовский Владимир wrote:
>
> Суть проблемы в том, что XeTeX - это не совсем TeX, хотя и очень на
> него похож.
Вот я и не понимаю, откуда берется это иррациональное убеждение:
мол, TeX, да не совсем? (Если на то пошло, то TeX в моем понимании --
это язык разметки, а вовсе не компилятор для него).
> Есть еще несколько раздражающий драйв XeTeX -> OpenType -> Mac OS.
Не знаю, что такое "драйв", и почему его направление именно таково,
а не, скажем, обратное. Начиналось всё, конечно, с MacOS (что, кстати,
естественно для SIL), но ведь только начиналось.
> И совершенно непонятно почему мне приходиться спорить по предмету,
> с которым почти не знаком?
Не я же этот разговор начинал.
> Но откуда fontinst берет кодировку? Из сделанных мануально
> etx-файлов! AFMtoENC может помочь такой файл получить.
Ну так etx-файлы-то поставляются вместе с пакетом, их не надо писать
заново. В случае с afmtoenc Вы вместо них, как я понимаю, используете
готовые таблицы кодировок, прошитые в программу. Так в чем же
принципиальная разница?
> Даже опытному пользователю ТеХ при желании
> попробовать сотни и тысячи ttf-шрифтов с ТеХ придется сталкнуться с
> БОЛЬШОЙ проблемой, если ограничиться помощью только fontinst.
С ужасом представляю опытного пользователя TeX, который трясущимися
руками устанавливает свой тысячный шрифт... :)
> Вот-вот! Об этом и AFMtoENC - дыры затыкать. Если у вас есть видение
> кодировки, лучшей чем T2A, то не так и сложно зарегистрировать ее на
> CTAN.
Пробовал когда-то, но не хочу больше, надоело. Ну, будет еще одна
экзотическая кодировка наравне со всякими cp1251-light, которую я буду
вынужден пиарить по форумам, потому что без меня о ней никто не узнает.
А Unicode уже тем хорош, что и без моих усилий проживет.
> XeTeX какие-то дыры может заткнуть, но ведь появятся новые.
> Например, не все символы из T2B, X2, LGR и др. есть в Unicode.
В LGR таких символов нет, если не считать одной сомнительной
вариантной формы. В X2 после принятия Unicode 5.1 осталось 4-5
регистровых пар, причем отсутствие этих символов в Unicode, на мой
взгляд, говорит лишь об их невостребованности. Ну, есть еще путаница
за счет того, что Unicode различает descender и tail как довески
к кириллическим буквам, а T2*/X2 -- видимо, нет. Это, кстати, лишний
аргумент в пользу того, чтобы во избежание подобных непоняток
предпочесть Unicode как более распространенный стандарт. А добавить
туда еще несколько букв всегда можно, буде они действительно кому-то
понадобятся.
> Во
> многих ttf-шрифтах есть глифы без уникодов, к которым можно
> обращаться, используя весьма громоздкий механизм tfm-файлов.
Глифы без юникодов могут добавляться в двух случаях: либо это
компоненты, служащие для построения других глифов, которые сами
по себе и не нужны, либо альтернативные формы, лигатуры и т. д.
В последнем случае доступ к этим глифам организуется через механизм
OpenType и других "умных" шрифтовых технологий, что, право же,
гораздо удобнее и эффективнее, чем tfm.
> Однако
> разделение символов на функционирующие по-разному категории...
Объясните, почему лично для Вас такое разделение неудобно.
> Можно
> ведь было ввести управляющий код "наложить со следующим" и думать не
> об алгоритмах наложения (об этом могли бы подумать авторы ПО), а о
> действительной унификации.
Unicode и не определяет никаких алгоритмов наложения, это многократно
подчеркивалось разработчиками стандарта.
> Ведь даже неграмотному человеку очевидно,
> что буква A одинакова и в греческом, и в румынском, и в болгарском.
Простите, это совершенно неочевидно. Например, в терминальных шрифтах
80-х годов, о которых лично я вспоминаю с ностальгией, кириллическое
заглавное "А" специально делалось так, чтобы отличаться от латинского.
Не говорю уж о возможности создания "исторических" шрифтов, имитирующих
различные стили письменности. В общем случае унифицировать буквы,
относящиеся к разным алфавитам, нельзя хотя бы для того,
чтобы избежать каши в таблицах кернинга. Это прекрасно поняли
разработчики Unicode, которые и стараются проводить данный принцип
неукоснительно.
> А вы попробуйте понаблюдать за каналом ошибок ttf2afm при работе с
> разными ttf-шрифтами (c otf все будет аналогично) -- на один символ
глиф, а не символ.
> притендуют по-нескольку уникодов!
И что здесь не так? Ну да, в Юникоде много внешне схожих символов.
Некоторые из них могут совпадать или различаться по форме в зависимости
от общего стиля шрифта, другие были клонированы просто по ошибке (что ж,
все мы люди) или из иных соображений. Поэтому вполне естественно, что
разработчики шрифтов иногда сопоставляют нескольким символам одну и ту
же картинку, физически хранящуюся в шрифте. Это вопрос всего лишь
удобства разработки шрифтов, а не самого стандарта. Если какие-то
программы принимают такую ситуацию за ошибку -- что ж, это их проблемы.
> Если скрещивать все со всем, то так, но не все скрещевается. :-)
В том-то и дело, что нельзя заранее предсказать, что с чем скрещивается.
Скажем, количество греческих акцентов вырастет в несколько раз, если
учесть все возможные наложения со знаками долготы и краткости.
> И, потом, нет никаких причин, кроме психологических, чтобы не
> расширить Unicode до 2^64. IMHO накладываемые диакритики в Unicode --
> это ошибка.
Напротив, это очень удобно. Дело в том, что декомпозиция акцентированных
символов нужна всё равно хотя бы для реализации алгоритмов поиска
(искать текст с акцентами очень неудобно). А если есть декомпозиция,
то каждый готовый композит добавляет головной боли разработчикам
шрифтов (нужно ведь, чтобы оба представления символа выглядели
идентично).
Если Вы с этим несогласны, объясните тогда свое видение проблемы.
> Но Unicode должен "освящать" символы либо утвержденные редкими
> древними документами (хотя тут много вопросов), либо частотой
> использования. А пытаться уследить за всеми возможными взрывами
> фантазии - это явная утопия.
Вот то-то и оно, что много вопросов. А как быть с орфографиями и
фонетическими системами, которые когда-то принимались в качестве
нормативных, но ныне забыты? На мой взгляд, именно здесь лежит
основной источник проблемных символов. Между прочим, многие буковки
из T2*/X2 -- именно этого сорта.
> > Потому что на практике дело ограничивается ею (кстати, в основном
> > тот
>
> Чьей практике? Я полагаю, что работающим, например, с вьетнамским
> языком (T5) это заявление не покажется совершенно верным
На самом деле, вьетнамский язык добавляет к стандартному набору только
один акцент и одну загогулину на букве. Другое дело, что _стандартные_
акценты там могут комбинироваться, и в рамках TeX'овской (но не
юникодовой) модели каждую такую комбинацию приходится считать за новый
акцент.
> Кто-то чего-то не учитывает, поэтому давайте не учитывать вместе с
> ним. Извините, но мне, например, такая логика не подходит.
Хорошо, ответьте тогда: лично _Вы_ учитываете кодировку tipa
в afmtoenc? Если да, то как Вы решаете обсуждаемую ниже проблему
с позиционированием глифа в ячейке?
> Фраза была о конкретном шрифте и любой шрифт имеет свою естественную
> кодировку.
Для TTF (кроме символьных) и OTF нет и не может быть другой
"естественной" кодировки, кроме Юникода. Или что Вы понимаете
под естественной кодировкой?
> А весь Unicode, пока он развивается, это некая
> нереализуемая вполне универсалия с множеством разрывов в кодах. Из-за
> последнего кодировка Unicode никак не может быть естественной,
> определяемой порядком.
Подумаешь, проблема. Многие восьмибитные кодировки содержат пустые места
(Adobe Standard вообще наполовину состоит из них). Это же не мешает
программам их обрабатывать.
> Писал об используемых знаках в современных языках, т.е.
> не о "ятях" и прочей исторической и узкоспециальной экзотике.
> Для всей с такими ограничениями латиницы и кириллицы хватает
> нескольких (менее 10) 256-элементных таблиц.
Объяснил же я, что _одной_ таблицы на _один_ язык во многих
случаях не хватает. Сделать несколько таблиц, конечно, можно,
но это повлечет за собой потребность в подвешивании довольно сложных
команд на активные символы, и к тому же между символами из разных
таблиц не будет кернинга.
> В UTF-8 есть "основные" символы ASCII, с которыми работают как с
> обычными ASCII, и прочие малонужные среднему англоговорящему
> пользователю "добавки". И эти "основные знаки" вполне помещаются в 8
> бит. Если бы это было бы не так, то нужды в UTF-7/8/16 совсем бы не
> было.
Причина совершенно иная. Символы ASCII действительно являются основными,
но не для естественных, а для машинных языков, к каковым, в частности,
относится HTML. И вот именно за счет тегов HTML и прочей разметки (а
они зачастую занимают 90% общего объема страницы) получается
существенная экономия WWW-трафика независимо от языка передаваемого
содержимого. Если же реализовать Вашу идею кириллического (или
греческого) UTF-8, то это не только не дало бы никакой экономии, но
и разбило бы интернет на несовместимые сегменты из-за различного
представления тех самых тегов.
> пользователю греку и американцу
> при работе с одинаковым греческим текстом подойдут одинаковые
> раскладки и соглашения о символьных последовательностях.
Ну так раскладку можно сделать любую, лишь бы набираемое содержимое
совпадало.
> У меня pdftex 1.40.7 c руководством rev. 1.675 от 25 января 2007
> года. Запустите поиск в Acrobat по слову OpenType. Должно появиться
> менее 10 ссылок. По одной из них читаем.
>
> If the font file name is preceded by a double <<, the font file will
> be included entirely--all glyphs of the font are embedded, including
> even the ones that are not used in the document. Apart from causing
> large size pdf output, this option may cause troubles with TrueType
> fonts, so it is normally not recommended for Type1 or TrueType fonts.
> But this is currently the only mode that allows the use of OpenType
> fonts. This mode might also be useful in case the font is atypical
> and can not be subsetted well by pdfTEX. Beware: some font vendors
> forbid full font inclusion.
Спасибо, понял. То есть, под OpenType понимается не технология создания
"умных" шрифтов, а конкретно формат OTF с PostScript-контурами. В таком
случае, я не понимаю, почему Вы придаете описанной здесь технической
детали такое большое значение, что считаете ее чуть ли не главным
недостатком pdftex. Ведь речь идет об использовании шрифта в качестве
простого контейнера для глифов, без учета всяких там "умных" таблиц
(для кернинга и прочего есть TFM). Ну и зачем тогда вообще использовать
OTF с pdftex, если формат Type 1 справится с этой ролью ничуть не хуже,
а сконвертировать в него не составляет никакой проблемы, причем,
в отличие от преобразования ttf->t1, никаких потерь информации или
изменений в контурах такая конверсия за собой не повлечет?
> Мне кажется, что в идеале, все должно быть сделано как в HTML:
> устанавливается основная кодировка, а при помощи &#....; вводятся
> отдельные уникоды.
Вот именно для этого и нужна нативная поддержка Unicode, без которой
немыслимы современные браузеры. Собственно, и в XeTeX, и в
Омеге давно есть нечто подобное: независимо от кодировки текста,
символы Unicode можно вставлять с помощью последовательностей вида
^^^^XXXX.
> Не все так однозначно. Символ в этой позиции отличается от символа в
> позиции C0 с обычным "А". В болгарских шрифтах вместо "Я" можно
> встретить иотированное "А" как в новом уникоде A656/7.
Йотированное "а" -- это совсем другой случай: его закодировали потому,
что оказалось невозможно с уверенностью сказать, является ли
современное "я" наследником этой буквы, или же "юса малого". А вот
между "азом" и современным "а" преемственность совершенно четкая.
Если развести их, то придется ровно с теми же основаниями разводить
и вообще всю историческую кириллицу с современной.
> Поэтому нет
> причин не включать такой символ в Unicode, тем более, что включать
> туда символы стали по самым разным и весьма мутным критериям и по
> нескольку раз на символ (см. греческие буквы).
Насколько я знаю, критерии постоянно уточняются. Старых ошибок никто
повторять не хочет.
> Неужели полная отсебятина? Трудно поверить, что кто-то работал без
> образца.
Нет, ну, разумеется, "I" с кругляшиком посередине -- вполне законная
орнаментальная форма для кириллического "I", но это же не повод выдавать
ее за отдельный символ (справедливости ради отмечу, что этим иногда
грешат и создатели Unicode).
> Эти символы совершенно непохожи, в T2D в позиции 1d находится символ
> \CYRzvat, напоминающий скорее U+1fbd или U+02bc.
Ах, ну да. Прошу прощения. На самом деле это -- вариантная форма для
символа 1b из той же кодировки. Ну и, скажите на милость, зачем было
вводить разграничение между старославянским и церковнославянским
придыханиями, если разница внешнего вида -- чисто стилистическая, а для
церковнославянского набора кодировка всё равно непригодна из-за
отсутствия буквотитл? В общем, еще один повод задуматься о том, для кого
и с какой целью эта кодировка создавалась...
> > 1e/1f -- не имеют шансов на включение в Unicode, т. к. представляют
> > собой сочетания тонкого придыхания с ударениями, с помощью которых
> > и должны набираться. Правда, тут есть общая проблема, связанная с
> > тем,
>
> Такой знак есть для греческого (U+1fce) - почему бы ему "не
> прописаться" и в кириллице?
Для греческого этот и ему подобные символы был включен ради
совместимости с какими-то старыми стандартами. С точки зрения Unicode
он бесполезен, ибо для набора текстов не применяется (здесь нужно
пользоваться либо готовыми композитами, либо комбинируемыми акцентами).
Но поезд давно ушел: из соображений совместимости символы больше
не кодируют, да и нет для кириллицы такого стандарта, который мог бы
оправдать потребность в подобном символе.
> Не понятно, почему именно так. Зачем неприменно нулевая ширина?
Неужели и правда непонятно? В общем-то, Юникоду и OpenType без
разницы, какая там ширина глифа у акцента: главное, чтобы была
правильно заданная якорная точка. Но принято делать в нулевую
ширину и со смещением влево, чтобы в крайнем случае, если придется
пользоваться шрифтом в приложениях без поддержки умных шрифтовых
технологий, хотя бы за счет простого перекрытия с предыдущим
глифом и хотя бы для самых простых случаев обеспечивалось некое
подобие того, что должно быть на самом деле.
> И в любом случае все можно скорректировать.
Объясните, как Вы собираетесьь это корректировать без помощи
виртуальных шрифтов (а ведь afmtoenc их не использует?).
--
Regards,
Alexej Kryukov <anagnost at yandex dot ru>
Moscow State University
Historical Faculty
|
|