Как с этим бороться
А теперь зададимся вопросом: а для чего вообще понадобилось связываться со шрифтовым хозяйством TeX? Может быть, TeXmacs умеет корректно обрабатывать содержащиеся в шрифтах лигатуры (под лигатурой в TeX понимается сочетание двух символов, которые должны быть заменены или дополнены третьим символом при компиляции документа)? Да нет, не похоже. Или программа знает, как обращаться с акцентами-модификаторами? Ничего подобного. Правда, в TeXmacs предусмотрены специальные клавиатурные комбинации для печати акцентированных латинских символов, в готовом виде содержащихся в кодировке T1, но вот составить новый символ из буквы и акцента нельзя. Мало того, если в LaTeX кодировка рассматривается как один из атрибутов шрифта, то TeXmacs, имея дело со внутренними кодировками TeX, ничего, в сущности, о них не знает. Шрифты в разных кодировках являются для него, как и для большинства визуальных редакторов, совершенно различными гарнитурами, и уже дело пользователя следить за тем, чтобы выбранный шрифт соответствовал языку текста.
Недоумение еще больше возрастает, когда мы обнаруживаем, что TeXmacs, оказывается, прекрасно умеет обращаться и со шрифтами, установленными в системе XWindow (по крайней мере, в формате Type 1 - насчет остальных ничего сказать не могу). Некоторый набор таких гарнитур (естественно, только латинских, и, естественно, в кодировке Adobe Standard, то есть, в сущности, в той же iso-8859-1) изначально доступен через меню программы. О такой мелочи, как различия кодировок, автор предупредить в документации. А эти различия, как мы уже убедились, как раз таковы, чтобы сделать абсолютно бессмысленными попытки сочетания шрифтового хозяйства TeX и XWindow в одном документе. Но, быть может, имеет смысл полностью переориентировать TeXmacs на шрифты Type 1, разом ликвидировав тем самым все вышеописанные проблемы?
Для разрешения этой задачи нам, во-первых, понадобится некий малый джентльменский набор кириллических гарнитур Type 1, состоящий из серифного, санссерифного и машинописного шрифтов. Я бы рекомендовал использовать шрифты в cp1251, но, если предпочтете koi8, не забудьте сконвертировать в эту кодировку файлы, отвечающие за русификацию интерфейса и русский перенос. Кроме того, для полноты операции желательно наличие совместимых гарнитур в западноевропейской кодировке. Далее я ради простоты картины буду исходить из предположения, что у нас имеется базовый набор коммерческих гарнитур от Paratype: NewtonC, PragmaticaC и CourierC для кириллицы, NewtonA, PragmaticaA и CourierA для западноевропейских алфавитов.
Шрифты эти, естественно, должны быть корректно установлены в системе XWindow. Далее мы могли бы сделать их доступными TeXmacs, внеся несколько дополнительных строк (по образцу уже имеющихся) в файлы TEXMACS_PATH/progs/fonts/x-fonts.scm и TEXMACS_PATH/progs/menu/main-menu.scm, которые, как это явствует из их названий, отвечают за загрузку шрифтов XWindow и конфигурацию меню. Но ведь мы хотели полностью отказаться от использования шрифтов системы TeX? Чтобы сделать это с наименьшими затратами, целесообразно переопределить шрифты roman и cyrillic, используемые программой по умолчанию. Для этой цели лучше всего создать новый файл, взяв за основу основу один из сценариев, ведающих загрузкой шрифтов (хотя бы тот же самый x-fonts.scm). Файл этот в нашем случае должен содержать следующие вхождения:
((roman rm medium right $s $d) (ps paratype-newtona-medium-r-normal $s $d)) ((roman rm medium italic $s $d) (ps paratype-newtona-medium-i-normal $s $d)) ((roman rm bold right $s $d) (ps paratype-newtona-bold-r-normal $s $d)) ((roman rm bold italic $s $d) (ps paratype-newtona-bold-i-normal $s $d))
((cyrillic rm medium right $s $d) (ps paratype-newtonc-medium-r-normal $s $d)) ((cyrillic rm medium italic $s $d) (ps paratype-newtonc-medium-i-normal $s $d)) ((cyrillic rm bold right $s $d) (ps paratype-newtonc-bold-r-normal $s $d)) ((cyrillic rm bold italic $s $d) (ps paratype-newtonc-bold-i-normal $s $d))
Далее создаются аналогичные строчки для гарнитур Pragmatica и Courier: помимо названий шрифтов меняется только показатель (т. е. roman) соответственно на (sansserif) и (typewriter). После чего надлежит сделать созданный файл доступным TeXmacs, прописав его загрузку в TEXMACS_PATH/progs/init.scm. Только загружаться он должен ранее всех прочих файлов из каталога TEXMACS_PATH/progs/fonts, если, конечно, у нас нет желания заниматься их редактированием на предмет истребления конфликтующих вхождений.
После этого не помешает просмотреть файлы из каталога TEXMACS_PATH/progs/keyboard (в первую очередь accents.scm) и вычистить из них те команды, которые имеют смысл только для кодировки T1. Кроиме того, целесообразно будет по-новому определить клавиатурные комбинации для печати наиболее распространенных типографских знаков препинания (то есть короткого и длинного тире, многоточия и парных кавычек всех видов). Нижеследующие определения будут работать правильно как для iso-8859-1, так и для cp1251:
("- -" "<символ с кодом 150>") ("- - -" "<символ с кодом 151>") (". . ." "<символ с кодом 133>") ("< <" "<символ с кодом 171>") ("> >" "<символ с кодом 187>") ("` `" "<символ с кодом 147>") ("' '" "<символ с кодом 148>") (", ," "<символ с кодом 130>")
Конечно, чтобы вставить в файл все перечисленные знаки, придется воспользоваться редактором со встроенной таблицей символов. Linux ведь не Windows - получить любой символ путем набора его кода на числовом блоке клавиатуры нельзя. Но это хотя бы не запретные коды из диапазона 0-32.
А теперь последний вопрос: стоит ли всем этим заниматься? Возможно, и стоит: ведь визуальных редакторов под Linux - раз, два и обчелся, а уж способность работать с многоязычными документами - свойство и вовсе уникальное. Только следует иметь в виду, что ваши наработки в TeXmacs не будут совместимы решительно ни с чем. Потому тот недостаток конвертера в формат LaTeX, о котором было сказано выше - далеко не единственный. Файлы, полученные с его помощью, производят страшноватое впечатление, и, главное, напрочь лишены той информации о шрифтовом форматировании и использованных языках, которая во внутреннем формате TeXmacs сохраняется достаточно эффективным способом. Ну а конвертеры для HTML и RTF пока лишь числятся в планах автора, и, соответственно, надежда на них слабая. Так что - думайте сами, решайте сами:
