|
|
13.07.08, 19:41, "Alexey Kryukov" CyrTeX-ru@vsu.ru:
> Вот все пугают несовместимостью, но никто не объясняет, о какой именно
> совместимости идет речь. Совместимость на уровне команд компилятора?
Суть проблемы в том, что XeTeX - это не совсем TeX, хотя и очень на него
похож. Есть еще несколько раздражающий драйв XeTeX -> OpenType -> Mac OS.
Все это, конечно, совершенно непринципиально. И совершенно непонятно почему
мне приходиться спорить по предмету, с которым почти не знаком? Может Вам
открыть тему "XeTeX: за и против"?
> > Речь была о том, что у меня возникли проблемы с подключением
> > произвольного Type 1, ttf и др. шрифтов к TeX. Оказалась, что нет
> > практически ничего для быстрой инсталляции таких шрифтов. Поэтому и
> > появилась утилита AFMtoENC, которая эту проблему как-то решает.
> Ну был fontinst, он тоже довольно удобен. Видите ли, на самом деле,
Но откуда fontinst берет кодировку? Из сделанных мануально etx-файлов!
AFMtoENC может помочь такой файл получить. И, вообще, fontinst, как и все
на TeX, -- это прежде всего документация. Если посидеть денек-два над
документацией к шрифту в формате fontinst, то потом действительно этот
шрифт будет удобно подключить к LaTeX.
> прикрутка шрифтов к TeX для опытного пользователя и раньше не составляла
> особой проблемы. Проблема в другом: мне просто не нравится модель, при
Проблема во времени. Даже опытному пользователю ТеХ при желании попробовать
сотни и тысячи ttf-шрифтов с ТеХ придется сталкнуться с БОЛЬШОЙ проблемой,
если ограничиться помощью только fontinst. А неопытному пользователю при
использовании имеющихся на CTAN средств и документации связываться с
ttf-шрифтами очень сложно, почти невозможно.
> которой приходится разбивать полноценный юникодовый шрифт на отдельные
> 8-битные блоки, к тому же довольно странно составленные. Я уже не раз
> высказывал свое мнение о кодировке T2A: это ж надо было умудриться
> не просто позаботиться о тюркских и др. языках, но еще к тому же и
> пожертвовать ради них нормальными славянскими символами из cp1251
> (предложив набирать их с помощью акцентов или унифицировав
> с латинскими). И благо бы азиатские символы были широко востребованы,
Вот-вот! Об этом и AFMtoENC - дыры затыкать. Если у вас есть видение
кодировки, лучшей чем T2A, то не так и сложно зарегистрировать ее на CTAN.
XeTeX какие-то дыры может заткнуть, но ведь появятся новые. Например,
не все символы из T2B, X2, LGR и др. есть в Unicode. Во многих ttf-шрифтах
есть глифы без уникодов, к которым можно обращаться, используя весьма
громоздкий механизм tfm-файлов.
> но ведь нет: пакетов языковой поддержки нет до сих пор, в шрифтах на
> этих местах -- черные дыры. Зато во всех славянских языках, кроме
> русского, теперь имеем проблемы с поиском в PDF. А если мне нужно
> набирать текст с "ятями", так и вовсе предлагают пользоваться ублюдочной
> T2D, для которой тоже нет и не может быть нормальной шрифтовой
> поддержки. А смысл грузить новую кодировку, если мне всего-то и нужна из
> нее пара символов?
Конечно, немного странно, что в разных кодировках много совпадающих символов,
хотя тут есть вполне здоровая логика (охватить одной кодировкой множество
языков). А вот логика Unicode становится какой-то все более мутной. Конечно,
это ведь "первый блин"... Unicode предоставляет каталог символов и это
делает его столь ценным. Однако разделение символов на функционирующие по-разному категории...
Можно ведь было ввести управляющий код "наложить со следующим" и думать не
об алгоритмах наложения (об этом могли бы подумать авторы ПО), а о
действительной унификации. Ведь даже неграмотному человеку очевидно, что
буква A одинакова и в греческом, и в румынском, и в болгарском. А так уже
сейчас в Unicode для одних символов не хватает места в 16-битах, а другие
клонируются.
> Но мало того: всё это кодировочное хозяйство не только выглядит странно,
> но к тому же так и не стало общепризнанным стандартом. Многим не
> нравится inputenc с его активными символами, многие предлагают свои
> модели русификации, основанные то на KOI8, то на какой-нибудь
> cp1251-light. А Вы говорите, совместимость. А с Юникодом таких проблем
> нет: он один.
А вы попробуйте понаблюдать за каналом ошибок ttf2afm при работе с разными
ttf-шрифтами (c otf все будет аналогично) -- на один символ притендуют
по-нескольку уникодов! Unicode -- это очень хорошо, но до совершенства ему
далеко и дальше похоже будет только хуже.
> > > Можно. Вообще-то как inputenc при использовании кодировки T1, так
> > > и пакет xunicode для XeTeX как раз и стараются подставлять готовые
> > > композиты, если таковые доступны. Однако создатели Unicode давно
> >
> > Ну тут их Кнут явно опередил! ;-)
> Из процитированного Вами отрывка моего постинга я так и не смог понять,
> кого и в чем именно он, по Вашему мнению, опередил.
Использовать накладываемые диакритические знаки Кнут предложил до появления
Unicode.
> > И есть еще SIL (если вы имеете
> > отношение к лингвистике, то аббревиатуру наверное знаете).
> Знаю хотя бы потому, что именно под крышей этой организации
> до последнего времени работал главный разработчик XeTeX :)
Спасибо за информацию. Это многое объясняет. В этом SIL работы велись и
ведутся по почти 10000 (!) языкам. С редкими языками работают в полевых
условиях и нужна чрезвычайная гибкость для возможности работатить с
ЛЮБЫМИ письменностями. Прежнее ПО SIL основывалось на растровых шрифтах и
поэтому, конечно, устарело.
> > Это очевидно, но в Unicode 2^32 кодов -- теоретически должно хватить
> > и на "композиты".
> Во-первых, не хватит, если учесть все возможные комбинации с двумя
> и более акцентами.
Если скрещивать все со всем, то так, но не все скрещевается. :-) И, потом,
нет никаких причин, кроме психологических, чтобы не расширить Unicode до 2^64.
IMHO накладываемые диакритики в Unicode -- это ошибка.
> Во-вторых, есть принципиальное решение разработчиков стандарта: новых
> композитов *не кодировать*. Я, как разработчик шрифтов, это решение
> всячески приветствую, т. к. иначе пришлось бы в каждой новой версии
> шрифта плодить кучу символов-клонов, при том что уследить за
> корректностью позиционировани их компонентов было бы абсолютно нереально
> для одного человека. Лучше уж сосредоточиться на уточнении правил
> позиционирования комбинируемых акцентов, которые подходили бы для
> большинства стандартных случаев.
Но Unicode должен "освящать" символы либо утвержденные редкими древними
документами (хотя тут много вопросов), либо частотой использования. А пытаться
уследить за всеми возможными взрывами фантазии - это явная утопия. Возможно
вы читали о приключениях Гулливера - там у одного из диковинных народов (лилипутов?)
слова писались во внутрь! Что мешает ввести в азбуку какому-нибудь современному
Кириллу совмещение А и Б? "Большинство стандартных случаев"...
> > звучит очень революционно, как о костях старого мира. "Все они"...
> Опять же не понял, что именно революционного в моих словах о плавной,
> поступательной эволюции свободных шрифтовых проектов, и при чем здесь
> кости старого мира.
Эмоции... Читая ваши слова о "старых ttf-шрифтах" возникли соответствующие
образы. А плавную эволюцию чего-угодно нового до определенного момента не так
уж и сложно обеспечить, например, хорошим финансированием, перспективами для
разработчиков и т.п.
> > А почему только в T1? Хотя, конечно, в unicode диакритик больше, но
> > это ведь вопрос не принципиальный, а вопрос востребованности...
> Потому что на практике дело ограничивается ею (кстати, в основном тот
Чьей практике? Я полагаю, что работающим, например, с вьетнамским языком
(T5) это заявление не покажется совершенно верным
> же набор и в T2*). Конечно, в каких-нибудь tipa акцентов побольше, но
> тут мы уже скорее всего будем ограничены стандартным дизайном в стиле
> cm (ведь при разработке шрифтовых пакетов редко кто учитывает эту
Кто-то чего-то не учитывает, поэтому давайте не учитывать вместе с
ним. Извините, но мне, например, такая логика не подходит.
> кодировку). Плюс еще надо засорять исходник командами для набора этих
> акцентов, что отрицательно скажется на его читабельности (ибо далеко
> не все такие команды интуитивно понятны).
Издержки... И ничто не мешает пытаться добиваться стандартизации
соответствующих команд и связывания их с Unicode, когда это возможно.
> > Никто не мешает использовать естественную кодировку шрифта или
> > разработанную самостоятельно.
> _Нельзя_ использовать естественную кодировку, если это Юникод.
Фраза была о конкретном шрифте и любой шрифт имеет свою естественную
кодировку. А весь Unicode, пока он развивается, это некая нереализуемая
вполне универсалия с множеством разрывов в кодах. Из-за последнего кодировка
Unicode никак не может быть естественной, определяемой порядком.
> > Конечно, иметь несколько tfm для одного
> > файла шрифта - это явные издержки технологии, но ведь об этом после
> > установки шрифта можно уже и не думать. Абсолютное большинство
> > текстов на алфавитных письменностях кодируется байтом на знак -
> Не расписывайтесь за абсолютное большинство. О такой "экзотике",
> как сирийский или арабский, я не говорю, но даже для греческого
> 8-битной кодировки в сущности недостаточно. Да, большинство
> акцентированных символов в таблицу вроде как и влезло, но набирать
> их приходится с помощью лигатур, а это разбивает кернинг, в том
> числе и в важных случаях. Со славянским та же история: акцентов
> много, набирать каждый с помощью символа backslash замучаешься.
> Только, в отличие от греческого, тут уж для всех акцентированных
> комбинаций заведомо нет места в таблице. Приходится идти на
Писал об используемых знаках в современных языках, т.е.
не о "ятях" и прочей исторической и узкоспециальной экзотике.
Для всей с такими ограничениями латиницы и кириллицы хватает нескольких
(менее 10) 256-элементных таблиц.
> такие извраты, как акценты в нулевую ширину -- трюк знакомый
> по текстовым процессорам, но абсолютно противоречащий идеологии TeX.
> И это ведь не юникодовые акценты с их тонким позиционированием,
> а просто тупой расчет на перекрытие акцента с предшествующим знаком.
Конечно, возможности техники растут и надо их использовать. Но речь лишь
об улучшенной реализации весьма старой идеи наложения знаков.
> > само
> > существование UTF-8 является этому наглядным примером.
> Поясните, каким образом существование UTF-8 (в которой все
> символы кроме блока ASCII кодируются как минимум двумя байтами)
> может служить этому наглядным примером.
В UTF-8 есть "основные" символы ASCII, с которыми работают как с обычными
ASCII, и прочие малонужные среднему англоговорящему пользователю "добавки".
И эти "основные знаки" вполне помещаются в 8 бит. Если бы это было бы не так,
то нужды в UTF-7/8/16 совсем бы не было. Разве не разумно для греческих
пользователей или использующих языки на основе кириллицы иметь свой UTF-8?
IMHO неплохо бы иметь коды переключающие контекст, смену "основного состава
знаков". К сожалению, это почему-то фиксируется на уровне ОС и документа
в целом, а иногда и навязывается сервером http... Кстати, Кнут придерживался
именно такого подхода, т.е. подхода, когда все неанглийские символы --
"дополнительные". Тут еще работать и работать...
> > все к Unicode - это маловероятная перспектива. Как всегда есть
> > высокие объединяющие концепции, но... Есть еще и проблема ввода
> > текстов.
> Об этом тоже много можно говорить. Мне представляется, что удобнее
> воспользоваться специальной раскладкой, либо, если это единичный
> символ, вставить его из таблицы, нежели писать длинные командные
> последовательности типа \cyryat (а если этот \cyryat на каждой
> строчке?). Тот же греческий в (pdf)LaTeX сейчас набирается с латинской
А чем мнемоничный \cyryat (подобные сокращения тоже можно описать в таблицах)
хуже U+048D, который нужно искать по таблицам? И раскладок получается
многовато и не факт, что пользователю греку и американцу при работе с
одинаковым греческим текстом подойдут одинаковые раскладки и соглашения
о символьных последовательностях.
> раскладки, и выглядит это примерно так: >En >arq~h| >~hn <o l'ogos...
> Набирать-то, может, и удобно, но вот читать замучаешься. Плюс еще
> проблема с конвертацией текста между TeX'ом и другими программами,
> которая для подобных способов представления никем толком не решалась.
Ну конвертация для любого программиста это не проблема. ;-) Была бы
поддержка "на том конце".
> > > Поясните, что Вы имеете в виду. С моей точки зрения, проблема прямо
> > > противоположная: достать из шрифта мы можем только те символы,
> > > которые прописаны в ENC-файле, то есть ровно 256 штук за раз и
> > > никак не больше.
> >
> > Похоже, что pdfTeX грузит их все (может 100, а может 10000) - это,
> > если я правильно понял, весьма серьезный недостаток.
> Можете ли дать ссылку на то место, где это написано?
У меня 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.
> > Да, конечно, здесь XeTeX похоже чемпион, но постоянная и полная
> > поддержка Unicode нужна наверное только строителю новой вавилонской
> > башни. :-) Обычным юзерам Unicode необходим только для
> > единовременного включения одного-другого редкого знака.
> А также для того, чтобы документы с "единовременно включенными" редкими
> знаками сохраняли совместимость между собой.
Мне кажется, что в идеале, все должно быть сделано как в HTML: устанавливается основная кодировка,
а при помощи &#....; вводятся отдельные уникоды. Но и метод который сейчас использует LaTeX вполне
позволяет сохранять совместимость, хотя, конечно, только для знаков из известных кодировок.
> > данные, опираясь на формальный источник - LaTeX-пакет unicode. На
> > основании этого источника в T2D нет уникодов для позиций
> > 1d-1f,80,81,84,85,88,94,96,a0,a1,a4,a5,a8.
> Не надо верить формальным источникам :) Давайте смотреть:
> 80/a0 -- обычное кириллическое "а", неизвестно зачем продублированное;
Не все так однозначно. Символ в этой позиции отличается от символа в позиции C0 с обычным "А".
В болгарских шрифтах вместо "Я" можно встретить иотированное "А" как в новом уникоде A656/7. Поэтому
нет причин не включать такой символ в Unicode, тем более, что включать туда символы стали по самым
разным и весьма мутным критериям и по нескольку раз на символ (см. греческие буквы).
> 88/a8 -- спорный символ: попытка как-то обозначить тот факт, что
> славянское десятичное i в нижнем регистре должно писаться с двумя
> точками. Заглавная форма искусственно сочинена так, чтобы чем-то
> отличаться от обычного I. Шанса на признание в Юникоде в качестве
Неужели полная отсебятина? Трудно поверить, что кто-то работал без образца.
> особого символа эта буква, видимо, не имеет, тем более, что i
> с двумя точками и так имеется. Так или иначе, ничто не мешает нам
> при перекодировке шрифта в T2D заполнять эти слоты стандартным I
> и украинским "йи";
> 85/a5 -- вариантная форма обычного "н", которая по этой причине не имеет
> шансов на включение в Юникод;
> 94/b4,96/b6 -- то же самое;
Все как с "А"...
> 1d -- CYRILLIC KAVYKA U+A67E, есть в Unicode 5.1;
Эти символы совершенно непохожи, в T2D в позиции 1d находится символ
\CYRzvat, напоминающий скорее U+1fbd или U+02bc.
> 1e/1f -- не имеют шансов на включение в Unicode, т. к. представляют
> собой сочетания тонкого придыхания с ударениями, с помощью которых
> и должны набираться. Правда, тут есть общая проблема, связанная с тем,
Такой знак есть для греческого (U+1fce) - почему бы ему "не прописаться" и в кириллице?
> что TeX'овские акценты по смыслу являются комбинируемыми, но при этом
> должны центрироваться в ячейке глифа. Т. е., конечно, можно сопоставить,
> например, титло символу U+0483, но в шрифте этот символ, скорее всего,
> будет иметь нулевую ширину и смещение влево, что сделает его непригодным
> для использования в TeX.
Не понятно, почему именно так. Зачем неприменно нулевая ширина? И в любом случае все можно
скорректировать.
|
|