[Comm] UTF-8 а Master 2.2

[Comm] UTF-8 а Master 2.2

[ivan shmykov]

Добрый день !

Вопрос, меня интересует поддержка UTF-8, а именно:
1. Поддержка в консоли (шрифты, раскладка и т.п.)
2. поддержка bash (readline), textutils, fileutils с точки зрения UTF8
3. поддержка UTF-8 в ncurses
4. Наличие качественных шрифтов TrueType либо Type1 (в UTF-8)
5. поддержка UTF-8 в ICEWM

Есть ли стратегическая цель по переходу к единой кодировке Unicode, или
она будет поддерживаться постольку поскольку.

С уважением,  
Иван

Re: [Comm] UTF-8 а Master 2.2

[Aleksey Novodvorsky]

ivan shmykov пишет:

>Добрый день !
>
>Вопрос, меня интересует поддержка UTF-8, а именно:
>1. Поддержка в консоли (шрифты, раскладка и т.п.)
>
Отчасти, но включение ее стандартными настройками не предусмотрено.

>2. поддержка bash (readline), textutils, fileutils с точки зрения UTF8
>
Поддержка UTF-8 базовыми утилитами Unix -- большая проблема, так как
требует их серьезного концептуального пересмотра  и тщательного аудита.
Мое _личное_ мнение -- сквозной переход Unix на UTF-8 locales
практически невозможен, так как приведет к большим проблемам с security.

>3. поддержка UTF-8 в ncurses
>
Нет

>4. Наличие качественных шрифтов TrueType либо Type1 (в UTF-8)
>
Да.

>5. поддержка UTF-8 в ICEWM
>
Вот этот вопрос не вполне понятен.

>
>Есть ли стратегическая цель по переходу к единой кодировке Unicode, или
>она будет поддерживаться постольку поскольку.
>
Ввод/вывод UTF-8 поддерживается в KDE, Gnome2, OOo, Mozilla, большинстве
программ с GUI. Это вовсе не требует использования UTF locales, хотя,
при желании, их тоже можно использовать.
Что касается перехода к единой (и единственной) кодировке всей системы,
то, на мой взгляд, это слишком комплексный вопрос, который не будет
реально решен в ближайшее время (я не беру в расчет декларации разных
вендоров). На мой взгляд, в рамках POSIX этот вопрос просто нерешаем.

Rgrds, AEN

>
>С уважением,  
>Иван
>  
>

Re: [Comm] UTF-8 а Master 2.2 [JT]

[Anton Kovalenko]

>>>>> Aleksey Novodvorsky writes:

    >>  2.  поддержка bash  (readline),  textutils, fileutils  с
    >> точки зрения UTF8

    > Поддержка  UTF-8   базовыми  утилитами  Unix  --  большая
    > проблема, так как  требует их  серьезного концептуального
    > пересмотра  и тщательного  аудита. Мое _личное_  мнение --
    > сквозной  переход   Unix  на  UTF-8  locales  практически
    > невозможен,  так  как  приведет  к  большим  проблемам  с
    > security.

Это очень странно слышать.  Сквозной переход на UTF-8 locales --
попросту  бессмысленен.  А  вот корректная  поддержка  multibyte
characters,  _частным  случаем_ которой  является  UTF-8 --  уже
становится традицией.

Что же  касается security, --  в системе, где имена  файлов case
sensitive, да  ещё с такой приличной кодировкой,  как UTF-8 (где
невозможен  \000  в  середине  строки, где  любой  встретившийся
символ  из  диапазона ascii  всегда  означает  самого себя,  где
никакой ascii-символ не  имеет альтернативного представления) --
непонятно, откуда возьмутся проблемы.

    >  Ввод/вывод  UTF-8  поддерживается  в  KDE,  Gnome2,  OOo,
    > Mozilla, большинстве программ с GUI.

Это   они  зря.   Ломают  устоявшиеся   и   _вполне  работающие_
классические иксовые  решения для  i18n, только для  того, чтобы
работать с символами "вне локального charset". Впрочем, некоторым из них
простительно -- портабельность под Windows требует жертв. 
Вот и Tk можно за это простить.

    >> 3. поддержка UTF-8 в ncurses
    >> 
    > Нет

Это при том, что upstream всё давно оттестировано и работает.

    > Что касается перехода  к единой (и единственной) кодировке
    > всей системы,

А эту реплику,  товарищи, мы с негодованием отметаем.  От неё за
версту  разит .... экзистенциоа...  ао... нализьмом  и неверием,
товарищи, в прогрессивную мощь  человечества. В общем, не на тот
идеал смотрите.

Единая   кодировка  для   обмена   информацией  между   иксовыми
приложениями  -  COMPOUND_TEXT.  Единая кодировка  для  удобного
хранения  строк  _внутри одного_  приложения  - wchars  (кстати,
постулировать,  что  "на  самом  деле wchars  --  это  unicode",
нельзя).

А для  utf-8 роль Единой  и Единственной вовсе не  подходит. Она
просто частный случай в зоопарке многобайтовых кодировок. Причём
один из самых простых частных случаев.

P.S.

Между   прочим,  довольно  интересно   наблюдать  за   тем,  как
развивается почти любой open-source проект, где одним из авторов
(или контрибуторов) становится японец. У такого проекта два пути
-- либо  там   появляется  нормальная  (с   моей  точки  зрения)
поддержка   i18n,   либо   рождается   "японизированный"   fork,
бесполезный всем остальным. Но первое бывает чаще, что не может
не радовать.

-- 
With Best /usr/bin/wishes, 
Anton Kovalenko /* http://kovalenko.webzone.ru */

Re: [Comm] UTF-8 а Master 2.2 [JT]

[Alexander Bokovoy]

On Thu, Mar 06, 2003 at 06:20:44PM +0300, Anton Kovalenko wrote:
>     >> 3. поддержка UTF-8 в ncurses
>     > Нет
> 
> Это при том, что upstream всё давно оттестировано и работает.
Работает одновременно для 8-битных кодировок и многобайтных без
перекомпиляции ncurses с выбором режима работы в run-time?

-- 
/ Alexander Bokovoy
---
I dote on his very absence.
		-- William Shakespeare, "The Merchant of Venice"

Re: [Comm] UTF-8 а Master 2.2 [JT]

[Anton Kovalenko]

>>>>> Alexander Bokovoy writes:

    >> >> 3. поддержка UTF-8 в ncurses
    >> > Нет
    >> 
    >> Это при том, что upstream всё давно оттестировано и работает.
    > Работает одновременно для 8-битных кодировок и многобайтных без
    > перекомпиляции ncurses с выбором режима работы в run-time?

Увы, нет. С перекомпиляцией и без выбора. (Но, естественно, тот,
что   с  поддержкой   wide   chars,  нормально   работает  и   с
восьмибитными кодировками).

В debian  собирают оба варианта  ncurses (как и  slang, кстати).
Часть зависящего софта собирают с поддержкой wide chars, а часть
-- без.

-- 
With Best /usr/bin/wishes, 
Anton Kovalenko /* http://kovalenko.webzone.ru */

Re: [Comm] UTF-8 а Master 2.2 [JT]

[Alexander Bokovoy]

On Thu, Mar 06, 2003 at 06:45:05PM +0300, Anton Kovalenko wrote:
> >>>>> Alexander Bokovoy writes:
> 
>     >> >> 3. поддержка UTF-8 в ncurses
>     >> > Нет
>     >> 
>     >> Это при том, что upstream всё давно оттестировано и работает.
>     > Работает одновременно для 8-битных кодировок и многобайтных без
>     > перекомпиляции ncurses с выбором режима работы в run-time?
> 
> Увы, нет. С перекомпиляцией и без выбора. (Но, естественно, тот,
> что   с  поддержкой   wide   chars,  нормально   работает  и   с
> восьмибитными кодировками).
> 
> В debian  собирают оба варианта  ncurses (как и  slang, кстати).
> Часть зависящего софта собирают с поддержкой wide chars, а часть
> -- без.
Я уже как-то говорил, что не считаю это хорошим решением. По существу, там
работы очень немного для того, чтобы довести до нормального состояния --
надо научиться активировать необходимую ветвь в зависимости от типа
кодировки в текущей локали. А уж как ветвь будет грузиться -- callbacks в
статически скомпилированной ncurses или dlopen в динамической версии -- 
не важно. Важно, чтобы выбор был в run-time, а не compile-time.


-- 
/ Alexander Bokovoy
---
Too much of everything is just enough.
		-- Bob Wier

Re: [Comm] UTF-8 а Master 2.2 [JT]

[Aleksey Novodvorsky]

Anton Kovalenko пишет:

>>>>>>Aleksey Novodvorsky writes:
>>>>>>            
>>>>>>
>
>    >>  2.  поддержка bash  (readline),  textutils, fileutils  с
>    >> точки зрения UTF8
>
>    > Поддержка  UTF-8   базовыми  утилитами  Unix  --  большая
>    > проблема, так как  требует их  серьезного концептуального
>    > пересмотра  и тщательного  аудита. Мое _личное_  мнение --
>    > сквозной  переход   Unix  на  UTF-8  locales  практически
>    > невозможен,  так  как  приведет  к  большим  проблемам  с
>    > security.
>
>Это очень странно слышать.  Сквозной переход на UTF-8 locales --
>попросту  бессмысленен.  А  вот корректная  поддержка  multibyte
>characters,  _частным  случаем_ которой  является  UTF-8 --  уже
>становится традицией.
>
Да, конечно.
Но -- не сквозная. Сквозная поддержка multibyte locales приведет к
описанным мною ранее проблемам.
Сквозная поддержка требует принципиально новых разработок.

>
>Что же  касается security, --  в системе, где имена  файлов case
>sensitive, да  ещё с такой приличной кодировкой,  как UTF-8 (где
>невозможен  \000  в  середине  строки, где  любой  встретившийся
>символ  из  диапазона ascii  всегда  означает  самого себя,  где
>никакой ascii-символ не  имеет альтернативного представления) --
>непонятно, откуда возьмутся проблемы.
>
При чем здесь имена файлов? Когда Вы имеете дело с "символом
неопределенной длины" -- проблемы неизбежны.
На самом деле, до сих пор всплывают проблемы c security даже при работе
в не-POSIX locale.

Rgrds, AEN

Re: Re: [Comm] UTF-8 а Master 2.2 [JT]

[Mikhail Zabaluev]

Hello Anton,

On Thu, Mar 06, 2003 at 06:20:44PM +0300, Anton Kovalenko wrote:
>
>     >>  2.  поддержка bash  (readline),  textutils, fileutils  с
>     >> точки зрения UTF8
> 
>     > Поддержка  UTF-8   базовыми  утилитами  Unix  --  большая
>     > проблема, так как  требует их  серьезного концептуального
>     > пересмотра  и тщательного  аудита. Мое _личное_  мнение --
>     > сквозной  переход   Unix  на  UTF-8  locales  практически
>     > невозможен,  так  как  приведет  к  большим  проблемам  с
>     > security.
> 
> Это очень странно слышать.  Сквозной переход на UTF-8 locales --
> попросту  бессмысленен.  А  вот корректная  поддержка  multibyte
> characters,  _частным  случаем_ которой  является  UTF-8 --  уже
> становится традицией.
> 
> Что же  касается security, --  в системе, где имена  файлов case
> sensitive, да  ещё с такой приличной кодировкой,  как UTF-8 (где
> невозможен  \000  в  середине  строки, где  любой  встретившийся
> символ  из  диапазона ascii  всегда  означает  самого себя,  где
> никакой ascii-символ не  имеет альтернативного представления) --
> непонятно, откуда возьмутся проблемы.
> 
>     >  Ввод/вывод  UTF-8  поддерживается  в  KDE,  Gnome2,  OOo,
>     > Mozilla, большинстве программ с GUI.
> 
> Это   они  зря.   Ломают  устоявшиеся   и   _вполне  работающие_
> классические иксовые  решения для  i18n, только для  того, чтобы
> работать с символами "вне локального charset". Впрочем, некоторым из них
> простительно -- портабельность под Windows требует жертв. 
> Вот и Tk можно за это простить.
> 
>     >> 3. поддержка UTF-8 в ncurses
>     >> 
>     > Нет
> 
> Это при том, что upstream всё давно оттестировано и работает.
> 
>     > Что касается перехода  к единой (и единственной) кодировке
>     > всей системы,
> 
> А эту реплику,  товарищи, мы с негодованием отметаем.  От неё за
> версту  разит .... экзистенциоа...  ао... нализьмом  и неверием,
> товарищи, в прогрессивную мощь  человечества. В общем, не на тот
> идеал смотрите.
> 
> Единая   кодировка  для   обмена   информацией  между   иксовыми
> приложениями  -  COMPOUND_TEXT.

Ну да, ужас пострашнее MIME, придуманный, наверное, в минуту
отчаяния от заскорузлости стандарта X.

> Единая кодировка  для  удобного
> хранения  строк  _внутри одного_  приложения  - wchars  (кстати,
> постулировать,  что  "на  самом  деле wchars  --  это  unicode",
> нельзя).

Насчёт неидентичности wchar_t и Unicode -- верно подмечено.
И многие среды разработки (не включающие в настоящий момент
GNU) даже с Unicode попали в ловушку 16-битных символов.
Всё это ставит под сомнение портируемость кода с wchar_t,
ведь даже принцип "один wchar -- один символ" не соблюдается.
Более того, наличие в Unicode комбинирующих символов
делает понятия "символ как номер в машинном представлении"
и "символ как единица текста" неэквивалентными, заставляя
прибегать к сложным схемам канонизации.
Насчёт удобства хранения не всё так однозначно:
строки из правильных (32-битных) wchar_t сжирают уж
слишком много места при преимущественном пользовании
ASCII.

> А для  utf-8 роль Единой  и Единственной вовсе не  подходит. Она
> просто частный случай в зоопарке многобайтовых кодировок. Причём
> один из самых простых частных случаев.

Замечательные свойства, подмеченные Вами, делают UTF-8
лучшим из возможных кандидатов на универсальную кодировку.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
I'm still waiting for the advent of the computer science groupie.

Re: [Comm] UTF-8 а Master 2.2 [JT]

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

On Fri, 28 Mar 2003 02:14:11 +0300
Mikhail Zabaluev <mhz@altlinux.org> wrote:

<skipped/>

> Более того, наличие в Unicode комбинирующих символов
> делает понятия "символ как номер в машинном представлении"
> и "символ как единица текста" неэквивалентными, заставляя
> прибегать к сложным схемам канонизации.
> Насчёт удобства хранения не всё так однозначно:
> строки из правильных (32-битных) wchar_t сжирают уж
> слишком много места при преимущественном пользовании
> ASCII.
> 
> > А для  utf-8 роль Единой  и Единственной вовсе не  подходит.
> > Она просто частный случай в зоопарке многобайтовых кодировок.
> > Причём один из самых простых частных случаев.
> 
> Замечательные свойства, подмеченные Вами, делают UTF-8
> лучшим из возможных кандидатов на универсальную кодировку.

Что подтверждается практическим использованием UTF-8 в качестве
внутреннего представления данных в [the] библиотеке для работы с
XML :)

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] UTF-8 а Master 2.2

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

On Thu, Mar 06, 2003 at 04:31:39PM +0400, ivan shmykov wrote:
> Вопрос, меня интересует поддержка UTF-8, а именно:
> 2. поддержка bash (readline), textutils, fileutils с точки зрения UTF8

В bash(readline) - да (в смысле поддержки ввода и вывода).

Что касается textutils и fileutils, то совершенно непонятно, о чем идет
речь.

> 3. поддержка UTF-8 в ncurses

Не включено в Master 2.2, скорее всего будет в Sisyphus и в следующей
версии.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: [Comm] UTF-8 а Master 2.2

[Mikhail Zabaluev]

Hello Dmitry,

On Thu, Mar 06, 2003 at 05:26:14PM +0300, Dmitry V. Levin wrote:
>
> On Thu, Mar 06, 2003 at 04:31:39PM +0400, ivan shmykov wrote:
> > Вопрос, меня интересует поддержка UTF-8, а именно:
> > 2. поддержка bash (readline), textutils, fileutils с точки зрения UTF8
> 
> В bash(readline) - да (в смысле поддержки ввода и вывода).
> 
> Что касается textutils и fileutils, то совершенно непонятно, о чем идет
> речь.

Ну, например, о поддержке классов символов в extended regexp,
о которой тут недавно говорилось. Или это надо адресовать
к glibc?

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
"Little else matters than to write good code."
-- Karl Lehenbauer