Re: XFree 4.0 released

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

> > > А ведь это бы решило проблему ввода для всех KOI8-like кодировок.
> > > да и CTEXT был бы короче.
> >   А чем это плохо, что CTEXT длинный? :-)
> Я так и написал: 'да и ...', а как насчет первого, собственно ISO-IR-111?
> 
> Как я сейчас нашел: http://www.sensi.org/lists/locale/y1999/msg00128.html
> именно вы предлагали заметить KOI8-like на ISO-IR-111, это будет?
> Я за - двумя руками.

  Да. Предлагал, но...
Больше всего мне понравилось то, что для него есть стандартная короткая
esc-последовательность. Сейчас перечитал то свое письмо - там половина
о том - как плохо то, что для koi8-r используется ее длинная кривая
sequence.
  Заменить полностью KOI8-R на ISO-IR-111 я и тогда не предлагал, хотя бы
потому, что - зачем людей озадачивать. Столько времени и сил потратили
на то, чтобы избавиться от ru_SU и объяснить, что "единственно правильная"
ru_RU.KOI8-R и - что теперь? Объяснять, что ru_RU.KOI8-R "масдай", а
правильно - ru_RU.ISO-IR-111?
  К тому же, koi8-r уже не просто зарегистрированый в IANA mime charset,
но и "preferred". (Я этому не рад, но и бороться не собираюсь).

  Что касается sequence. Во-первых, кроме "кривой" для koi8-r, сейчас
там появилось много новых не менее "кривых". Так что, если уж решать
проблему, то для всех сразу.
  А во-вторых, я нашел - в чем проблема и как ее исправить (в частности,
я советовал добавить в XLC_LOCALE секцию XLC_CHARSET_DEFINE, что практически
устраняет все неприятные последствия "кривизны").
  Так что, меня теперь не сильно волнует, что для koi8-r используется
длинная нестандартная sequence. И постараюсь сделать так, чтобы это
вообще никого не волновало. :-)

  Что касается наличия очень похожих таблиц для koi8-r и koi8-u.
Ну, пару таблиц я уже выкинул из Xlib. Скоро избавлюсь и от остальных.
Вообще говоря. Так как это сейчас сделано в "иксах" - koi8-r является
просто подмножеством koi8-u.
  Поэтому, фонты например можно было бы держать koi8-u и не дублировать
их koi8-r. Локаль тоже можно было бы оставить только koi8-u.
  Небольшая разница есть только в расскладках клавиатуры. Но они то как-раз
не привязаны к локали (а к алфавиту - "кириллице").
  Поэтому их правильнее называть не ru, ua, be. А например cyrillic(ru),
cyrillic(ua), cyrillic(be).

  Ну и... Все согласны отказаться от koi8-r и оставить koi8-u?
  Если да - то пусть она так и называтся (как я уже писал, патриоты могут
считать, что U - это Universal или Universe, а не Ucranian :-) и зачем
ее переименовывать в iso-ir-111?
  А если нет - то что тогда говрить о новой, пусть и более всеобщей кодировке?

> >   Кстати, рекомендую - справочник по всем esc-sequences iso2022
> > http://www.cwi.nl/people/dic/english/codes/2022/esc.html
> Если кто еще интересуется там 'dik' вместо 'dic'
  Sorry. Опечатался.

> И еще, тут мне попалась старая брошюра: DEC VT330/340 - я давно ее не листал,
> так вот, там есть интересная вещь - все символы в C1 имеют замену на 
> Esc-последовательность. Более того, в этих самых терминалах, можно
> было выключить 8-bit control, после чего можно было смотреть даже
> cp866 - большие буквы. Если бы такое было бы в Xlib - это бы решило
> многие проблемы с символами в C1. Это реально протолкнуть в XFree ?

  Проталкивайте. :-)
  Можете начинать прямо здесь. :-)
  Поскольку автором последней редакции CTEXT парсера (да и большинства
конверторов используемых при encoding_name koi8-r) являюсь я. А кроме меня
(ну может быть еще Bruno Haible) эта часть похоже никого из xfree86 не волнует. 

  А если серьезно.
  "Все символы C1 имеют замену" в iso2022. CTEXT является сильно урезаным
подмножеством iso2022. Причем одно из ограничений в том, что он в принципе
восьмибитный и в семибитный никак не переключается.
  Следовательно - надо расширять стандарт CTEXT, а потом уже можно его
воплощать в парсере.
  Но это расширение (я думаю) никого уже не заинтересует. Поскольку все
"специалисты по локали" считают, что для обмена "мультичарсетовыми" строчками
надо использовать UTF-8. А CTEXT доживает последние дни (годы), пока еще не
все приложения (библиотеки, ОС'ы) явялются unicode aware.

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