Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Sergey Vlasov <vsu@mivlgu.murom.ru>]

On Sun, 11 Mar 2001 21:28:51 +0200
Alexander Bokovoy <ab@avilink.net> wrote:

> On Sun, Mar 11, 2001 at 10:21:36PM +0300, Sergey Vlasov wrote:
> > On Sun, 11 Mar 2001 20:53:50 +0200
> > Alexander Bokovoy <ab@avilink.net> wrote:
> > 
> > > On Sun, Mar 11, 2001 at 08:43:18PM +0300, Sergey Vlasov wrote:
> > > > > Но там еще есть ошибки, так что я --with-native-locale убрал, и
> > > > > sylpheed-0.4.62cvs4 (из Sisyphus, покореженный на предмет сборки
> > > старым
> > > > > rpm) работает, и не падает (им, собственно, и пишу :-). Но опять
> же
> > > с
> > > > > XFree 3.3.6.
> > > > 
> > > > Продолжаем исследование. У меня не совсем Sisyphus - glibc пока
> 2.1.3
> > > > с Appendix, XFree 3.3.6, но rpm, perl, bash, tar, bzip2, fileutils
> > > > свежие, так что пакеты из новых src.rpm собираются. Итак,
> результаты:
> > > > 1. "Wide characters" для mbstowcs (glibc) и для Xwc* - это не одно
> и
> > > > то же! По крайней мере, сейчас в gdb проверил - в 1.2.9-ipd4mdk
> > > > gdk_draw_text_wc передает в XwcDrawString текст в Unicode (но с
> родным
> > > > порядком байтов) - именно так работает glibc (2.1.3). Но на экране
> > > > рисуется, похоже, младший байт этого значения в кодировке koi8-r.
> В
> > > > версии 1.2.8 проблем нет - там все преобразования идут через
> Xmb/Xwc*,
> > > а
> > > > в 1.2.9 при их смешивании получается ерунда. Возможно, это
> проблема
> > > > старой glibc (пока не обновил, тем более, говорят, процесс
> сложный, а
> > > > описания я не нашел; тащить инсталлятор нет возможности). Или же
> > > виноват
> > > > старый Xlib 3.3.6.
> > > В новой glibc (2.2.2) порядок следования байт в Wide characters
> зависит
> > > от ендианности машины, в частности, на PC -- LE.
> > 
> > Так у меня не 2.2.2, а 2.1.3, и тоже LE (по крайней мере в тестовой
> > программке в массиве из wchar_t после mbstowcs() вижу нормальные
> > значения ISO10646/Unicode, а не с переставленными байтами). Видимо,
> это
> > как раз и есть кодировка "INTERNAL", использующаяся в gconv. А вот
> iconv
> > при запросе ISO10646 вроде бы должен выдавать BE независимо от машины.
> Я не рекомендую пользоваться именем кодировки UNICODE в iconv -- оно не
> портабельное. А вот UCS2-LE/BE -- портабельные. Собственно, поэтому
> многие
> пользуются UTF-8. Это лирическое отступление, а если серьезно -- в glibc
> такого
> имени (ISO10646) для кодировки нет, там только UNICODE, но он выдает
> с привязкой к порядку байт на машине. INTERNAL, кстати, означает UCS2-LE
> на PC.

Оппс, имел в виду UCS4 - там именно BE. А по поводу INTERNAL в libc.info (glibc iconv Implementation) написано, что это почти UCS4, но с родным порядком байт (и действительно, sizeof(wchar_t) == 4). Как я понимаю, именно INTERNAL и используется для wchar_t.

> > Итак, получается, что wchar_t в glibc - это ISO10646 с родным для
> машины
> > порядком байт, и в glibc 2.1.3, и в 2.2.2. Тогда возникает вопрос, как
> > рассматривают wchar_t функции Xwc* - тоже как ISO10646 или по-своему?
> Во
> > всяком случае, у меня на 3.3.6 XwcDrawString получает на вход юникод и
> > рисует вместо него, похоже, просто младший байт. Может быть, в 4.x это
> > исправлено? Завтра придется смотреть на разных машинах и сравнивать.
> Насколько я знаю, именно в 4-тых сериях и исправлено.

Тогда дальнейшее исследование придется отложить до завтра.