From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 11 Mar 2001 23:08:54 +0300 From: Sergey Vlasov To: sisyphus@linuxteam.iplabs.ru Subject: Re: [devel] Re: [sisyphus] I gtk+-1.2.9 Message-Id: <20010311230854.126edbac.vsu@mivlgu.murom.ru> In-Reply-To: <20010311212849.I1408@avilink.net> References: <3AA141C7.976F227F@logic.ru> <20010311171049.39928f29.vsu@mivlgu.murom.ru> <20010311204318.52dc0fad.vsu@mivlgu.murom.ru> <20010311205349.G1408@avilink.net> <20010311222136.1e3ca241.vsu@mivlgu.murom.ru> <20010311212849.I1408@avilink.net> X-Mailer: Sylpheed version 0.4.62cvs4 (GTK+ 1.2.8; i586-mandrake-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Sender: sisyphus-admin@linuxteam.iplabs.ru Errors-To: sisyphus-admin@linuxteam.iplabs.ru X-BeenThere: sisyphus@linuxteam.iplabs.ru X-Mailman-Version: 2.0 Precedence: bulk Reply-To: sisyphus@linuxteam.iplabs.ru List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Archived-At: List-Archive: List-Post: On Sun, 11 Mar 2001 21:28:51 +0200 Alexander Bokovoy 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 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-тых сериях и исправлено. Тогда дальнейшее исследование придется отложить до завтра.