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

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

  Теперь можно перейти к самому XLC_LOCALE.

  Секцию для фонтов пока пропустим и начнем с XLC_XLOCALE

encoding_name		<имя чарсета>
  Фактически - название чарсета, вводимого с клавиатуры. Напомню, что
он важен только для GR кодов. Если вводимый символ < 128, то его можно
интерпретировать и как GL из того же чарсета и как просто ascii (GL от iso8859-1)
По этому параметру процедуры X[mb|wc|]LookupString определяют
  - как перекодировать keysym в байт
  - как потом сделать из него wc/mb/ct
(не могу удержаться - кривизна страшная. Сразу "подавляются" keysym, которые
не укладываются в этот encoding_name, хотя их можно было бы корректно перевести
в ctext, например. Но это не "баг", а кривизна идеологии.)

mb_cur_max              <число>
  максимальное количество байтов в mb представлении. Обратите внимание, что
это - max. Каждый конкретный символ может быть и короче.
  Для iso8859-кодировок  всегда - 1.

state_depend_encoding   <true/false>
  Имеет смысл для некоторых CJK. Зависит ли интерпретация очередного символа
от предыдущих (предыдущего). Или другими словами - от текущего сотстояния
процедуры конвертации.
  Для iso8859-кодировок  всегда - False.

wc_encoding_mask        \x30000000
wc_shift_bits           7
  Относится к преобразованию в wc (и из него). К ним надо еще рассматривать
и wc_encoding из описаний кодесетов (об этом ниже).

wc_encoding_mask - "маскирует" те биты, которые "различают" чарсет.
То есть, в данном случае, wc может представлять четыре разных чарсета,
отличающихся тем - что у них в "замаскированной" части (0,1,2,3)

А wc_encoding (в описаниях разных кодесетов) как-раз указывает - что
в эту часть надо вписать, в зависимости от кодесета.

wc_shift_bits - определяют - когда несколько байтов (из mb) "упаковываются"
в один wc - на сколько бит сдвигать один относительно другого. Соответственно,
это же число определяет и - сколько бит от каждого байта надо взять.
  Обратите внимание, для всех кодировок типа iso8859, обычно если байт больше
128, то при преобразовании в wc из него берутся только семь бит.
То есть, в младшей части wc всегда будет семибитный код, а восьмой бит
"переезжает" в "замаскировнную" часть wc (точнее - туда обычно вписывается 3).
  (тоже не очень хорошо. Насколько я смог найти документации, обычно для
простых кодировок при преобразовании в wc, байт просто копируют туда. Это
преобразование можно описать как
wc_encoding_mask        \x00000000
wc_shift_bits           8
или
wc_encoding_mask        \x00000080
wc_shift_bits           7
  но, почему-то, в локалях xfree86 утвердился другой стандарт, который имеет
смысл для "длинных" кодов CJK)

use_stdc_env            True/False
  Имеется ввиду, что при приобразовании wc->mb (mb->wc) можно и нужно
использовать процедурки libc - mblen, mbtowc, wctomb и т.п.
  Кстати, от этого параметра очень сильно зависит - что получится на выходе
XwcLookup* (во всяком случае для iso8859). Как я уже сказал, стандартная
mbtowc просто скопирует байт в w_char (естественно, все прааметры типа wc_*
игнорируются). А если этот параметр false (кстати - так "по умолчанию") -
то преобразование будет - как я уже описал выше.
 (очередная кривизна - в XLC_LOCALE для iso8859-5 этот параметр - true,
а в koi8-* его нет, то есть - false. Кто виноват? И как правильнее?)

force_convert_to_mb     True/False
  На этот можно вообще не обращать внимание. Он означает, что при
преобразовании "чего-то во что-то" (я сам еще не разобрался), лучше сначала
сконвертировать в mb, а потом - в то, что нужно. Для кодировок iso8859
он вообще смысла не имеет и реально используется только в том куске,
который обрабатывет JIS.

  Продолжение следует...

-- 
 Ivan U. Pascal         |   e-mail: pascal@tsu.ru
   Administrator of     |   Tomsk State University
     University Network |       Tomsk, Russia