Re: [gentoo-dev] CJK testing

[Marko Mikulicic]

Thomas Beaudry wrote:
>
>> > I'm with Marko.  The use flag should be unicode.  More accurate
>> > description of what it's for even if people are only using it for
>> > CJK support at the moment.
>>
>> The reason that CJK was chosen was that untill postgresql, I have only
>> ever seen --enable-multibyte used for adding Asian font capabilities. It
>> wasn't till this response that I was even aware that postgresql used it
>> to add support for unicode (and others as well). I'll have to look at
>> this issue in more depth because on occasion adding Asian support
>> sometimes kills Russian or Greek support. May have to add an additional
>> flag.

So, when someone wants russian and greek (together->unicode) in 
postgresql it has to enable CJK and then possibly break some other 
applications which have nothing to do with pgsql.

>>
>> Unicode in this case is better, but not actually more accurate as
>> unicode is just 1 of many encodings that postgresql activate with
>> --enable-multibyte. multibyte or i18n might be more appropriate?

I use always unicode inside the database because the client can choose
the encoding for the connection and an eventual conversion happens on
the fly. But someone may want to store the data internally in a specific 
encoding for performance issues.
  Automatic conversion can be disabled (and this saves performance and code
size).
  This make me think about the possibility to have a finer granularity
in configuring an ebuild:

1) Combinations of global use flags activate a ebuild-local use flag.
2) ebuild-local use flags have effect only on a given ebuild

for example:

global use flag: "unicode" -> local flag: "postgresql/multibyte"
global use flag: "cjk" -> local flag: "postgresql/multibyte"

pseudo code in ebuild: if use unicode or use then multibyte

"local" (a better name...) use flags are like use flags but prefixed 
with the ebuild name path.

/etc/make.conf:  USE="... cjk -postgresql/unicode-conversion"

this flags enable multibyte for Chinese-Japanese-Korean but
without the overhead of conversions to other encodings.

If this make sense to you I will elaborate it better and send
a feature bug. But if it is stupid tell me now :-)

>
> Multibyte sounds like the best to me.  i18n uses both single- and multi-
> byte fonts so wouldn't be entirely accurate.

Multibyte is not bad as it is a 1-to-1 mapping with the configure flag,
but I think i may be confusing. The word "multibyte" doesn't associate
with text and encoding but to actual implementation.

Marko