Re: XFree 4.0 released

["Eugene B. Byrganov" <E.B.Byrganov@inp.nsk.su>]

> > Как я сейчас нашел: 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?

Какая же она (koi8-u) "Universal"? Universal это koi8-e или же нечто,
что я назвал koi8-5 или же koi8-f - как на czyborra

И как я понимаю из lcCT.c, имя iso-ir-xxx не используется само по себе:
 
    /* X11 registry name       MIME name         ISO-IR      ESC sequence */

    { "ISO8859-1:GL",       /* US-ASCII              6   */  "\033(B" },
    { "ISO8859-1:GR",       /* ISO-8859-1          100   */  "\033-A" },
    { "ISO8859-2:GR",       /* ISO-8859-2          101   */  "\033-B" },
    { "ISO8859-3:GR",       /* ISO-8859-3          109   */  "\033-C" },
    { "ISO8859-4:GR",       /* ISO-8859-4          110   */  "\033-D" },
    { "ISO8859-5:GR",       /* ISO-8859-5          144   */  "\033-L" },

По крайне мере нужно добавить строку:
    { "KOI8:GR",            /*  KOI8-x             111   */  "\033-@" },

и алиас KOI8-E на него, так как это имя уже используется в Xlib для шрифтов.
(Конечно и полную таблицу).

И самое главное - это внутренние имя в Xlib (в XLC_LOCALE), и не о какой 
замене ru_RU.KOI8-R на ru_RU.ISO-IR-111 речь не идет  - есть же
'encoding_name STRING'.

>   А если серьезно.
>   "Все символы C1 имеют замену" в iso2022. CTEXT является сильно урезаным
> подмножеством iso2022. Причем одно из ограничений в том, что он в принципе
> восьмибитный и в семибитный никак не переключается.
То есть, если будет строка типа: ESC N, то Xlib не поймет что это SS2?
И если так, то вроде не должно быть проблемы заменить поведение Xlib,
по крайне мере для ISO-8859-like кодировок, кстати, а среди полей
в XLC_LOCALE точно нет такого?


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




-- 

                      С наилучшими пожеланиями, Евгений Бырганов.
                      Best regards, Eugene Byrganov.

  mailto:E.B.Byrganov@inp.nsk.su
  work - http://www.inp.nsk.su/