On Tue, 30 Jun 2009 09:56:38 +0200, Paolo Bonzini wrote:

> On 06/30/2009 12:02 AM, Yoshiki Ohshima wrote:
...
>>    I think a future version basically shouldn't try to "print" a
>> Chararacter, but print out the code point and to display a character,
>> you do have to supply the extra infomation.  (Character object is
>> convenient, but you can go with all String objects, if you like.)
>
> Exactly my point.  When you know a language you can go with String  
> objects and then you can avoid #leadingChar.

Sorry for disturbing your circles, guys. But replacing a leading char by  
another sequence of chars ? what would be the purpose (other than the fun  
of it) ?

Paolo, since 1999 RFC 2482 awaits formal acceptance, so it does not really  
address any urgent need nor really solves a critical problem ?

Also, RFC 2428 was specifically designed for _transfer_ protocols which  
want in-bound language tag information.

Besides of that, RFC2428 cannot do without Unicode (but Unicode encodes  
scripts, not languages, so apps cannot be compatible without costly  
changes).

So why would I want to have a transfer encoding in my storage encoded  
image, a transfer encoding that eats up space in stored strings, and does  
not work with 8bit strings but requires wide strings ?

Perhaps I'm missing something ?

/Klaus

> Paolo
>



-- 
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein