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

[Alexander Bokovoy]

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.

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

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |    Aurora R&D team 
Minsk Linux Users Group |    www.minsk-lug.net    |  www.aurora-linux.com  
    ALT Linux Team      |    www.alt-linux.org    | Architecte Open Source
-- Out of sight is out of mind.
		-- Arthur Clough