XLC_LOCALE. Продолжение 3.

[Ivan Pascal <pascal@info.tsu.ru>]

  В блоке описания кодесетов может встретиться еще несколько директив.

  Прежде чем говорить о них, надо заметить, что некоторые параметры из
XLC_LOCALE имеют в качестве аргумента список из конструкций вида
[***,***]->*** (в "сырцах" их называют "scope").

  Обозначают они преобразование кодов - "перенос" или "сдвиг".
Первое число - начало исходного диапазона кодов
второе - конец исходного диапазона
число после стрелки - начало диапазона "куда сдвигать"
естественно, конец "целевого" диапазона просто вычисляется.

  Если код (это может быть байт или w_char) попадают в исходный дипазон,
то он сдвигается соответственно (на разность "начал дипапазонов").
  Естественно, такая конструкция может использоваться и для сдвига в обратную
сторону.

  Итак, в блоке cs*{...} могут встретиться еще такие "слова"...
  (для iso8859 они смысла не имеют)

mb_conversion	<scope>
  Описывает дополнительные преобразования кодов при конверсии из/в mb.

ct_conversion	<scope>
  То же, что и предыдущий но для конверсии из/в ctext.

ct_conversion_file
   Судя по всему, задумывалось это так, что scope для ct_conversion можно
будет подчитать из отдельного файла. Но реально, эта инструкция сейчас
никак не интерпретируется.

  Для описаний кодесетов - это все.

  Следующий блок
XLC_CHARSET_DEFINE ... END XLC_CHARSET_DEFINE

  Встречается в некоторых CJK. Но лучше бы его использовали почаще.
В нем описываются чарсеты. В основном - размеры чарсета (96 или 96^N)
и "назначатели" - esc-sequences, которые используются в ctext.
  Сейчас все, кто добавляет новые кодировки в Xlib, просто вписывают
"назначатели" и имена чарсетов во внутренние таблицы Xlib.
  Это плохо потому, что...
  - для всех новых чарсетов используют "нестандартные" секвенсы, как это
предписано CTEXT. Само по себе это нормально, но ...
  - практически все авторы (начиная с ache) формируют эти секвенсы
неправильно. Xlib работает только потому, что одну и ту же последовательность
вписывают в две таблицы - для формирования ctext и для "раскодирования" ctext.
Пока Xlib раскодирует то, что сама же "накодировала" - все будет нормально
(хотя это - опять же кривизна идеологии; для обмена данными внутри Xlib
не надо было использовать ctext, это самый "избыточный" способ).
А вот если какая-то программа захочет пообщаться с Xlib строчками в формате
ctext, то ... будет плохо.
  - вторая проблема (опять же связаная с кривизной идеологии) - Xlib в своих
таблицах не хранит полное описание чарсета (side, размер и т.п.), а при старте
"вычисляет" их из вида sequence. Если из "стандартных" секвенсов можно
извлечь всю эту информацию (внутри sequence используются разные знаки,
в зависимости от того - какой размер и side чарсета), то в "нестандартных"
этих сведений нет "по определению" (по стандарту CTEXT). Из-за этого, сама же
Xlib интерпретирует их неправильно и местами "глючит".

  Итак. В этой секции идут блоки - описания чарсетов
csd* {...}

  Внутри блока могут быть следующие параметры

charset_name
  Понятно из названия. Например - KOI8-R

side
  Опять же - очевидно. Там может быть GL, GR или none

length	<число>
  Длина одного символа в байтах. Напомню, что это не mb, а ct. То есть,
этот параметр определяет N в размере кодесета (96^N).
  Для iso8859 - 1.

gc_number	<число>
  Размер чарсета. Может быть 96 или 94. Обычно, для всех GR - 96.

string_encoding	<true/false>
  Вот это - не знаю пока.

sequence
  Это не вся sequence, а только ее начало. В нее еще добавляется слово
заданное следующим параметром...

encoding_name
  В данном контексте - просто означает то имя, которое будет вставлено
в sequence.

  Для koi8-r последние две строчки должны быть
sequence	\x1b%/1
encoding_name	koi8-r
что в результате даст полный "назначатель" - \033%/1\200\211koi8-r\002

В этом блоке - все.

  Надо заметить, что, к сожалению, сейчас эта секция мало полезна.
Описания чарсетов из нее используются для раскодирования ctext и
"закодирования" при выдаче в прикладную программу. А те строчки, что Xlib
делает "сама для себя" все-равно кодируются по внутренней таблице.
  Поэтому, если там sequence неправильная, то описание чарсета в XLC_LOCALE
только все испортит.

  К тому же, описать новый чарсет можно в XLC_LOCALE. Но нет никакого способа
(кроме добавления в исходники) описать таблицу перекодировки keysym в байты.

  Продолжение следует...
-- 
 Ivan U. Pascal         |   e-mail: pascal@tsu.ru
   Administrator of     |   Tomsk State University
     University Network |       Tomsk, Russia