[squeak-dev] #leadingChar (Re: The future of Squeak & Pharo))
Paolo Bonzini
bonzini at gnu.org
Tue Jun 30 07:56:38 UTC 2009
On 06/30/2009 12:02 AM, Yoshiki Ohshima wrote:
> At Mon, 29 Jun 2009 11:13:24 +0200,
> Paolo Bonzini wrote:
>> You're free to have your opinion on Han unification. Many people share
>> it, many people don't. But the fact is, only Squeak does it this way
>> and it does have as many problems as it solves.
>>
>> For another way to encode languages see
>> http://www.isi.edu/in-notes/rfc2482.txt.
>
> As Eliot wrote, an interactive environment has different constraint.
> #at: is one of them, and $- notation for specifying a character
> etc. (say print-it for it should print something) should provide some
> workable solution.
#at: is not one of them, language tags should not be skipped just like
soft hyphens (U+00AD, also known as hyphenation hint) should not.
Regarding specifying a character, I don't think it happens *so* often
that a Japanese wants to specify explicitly a Chinese shape and vice
versa for a single character. Just choose a default font based on the
current local, and for the occasional time when you do know the language
use something like this:
String>>withLanguageTag: aString
^(Character codePoint: 16rE0001) asString,
(aString collect: [:ch|Character codePoint: ch value+16rE0000]),
self
Character>>withLanguageTag: aString
^self asString withLanguageTag: aString
(Character codePoint: 16r4000) withLanguageTag: 'JAPANESE'
> 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.
Paolo
More information about the Squeak-dev
mailing list
|