From: Ben Monroe (bendono@gmail.com)
Date: Tue Oct 30 2007 - 15:06:00 CST
On 10/30/07, vunzndi@vfemail.net <vunzndi@vfemail.net> wrote:
> Quoting Ben Monroe <bendono@gmail.com>:
>
> > On 10/30/07, John H. Jenkins <jenkins@apple.com> wrote:
> >
> >> On Oct 29, 2007, at 6:28 PM, Andrew West wrote:
> >>
> >> > On 29/10/2007, Peter Constable <petercon@microsoft.com> wrote:
> >> >>
> >> >> I guess I assumed that that was never intended to provide a
> >> >> substitute for encoding the characters needed for Zhuang text -- it
> >> >> would be a terrible way to represent Zhuang text, though I suppose
> >> >> you can argue (as you have done) that it's valid.
> >> >
> >> > I'm sure that John has never suggested that IDS sequences should be a
> >> > substitute for encoding, merely that given what the Unicode Standard
> >> > currently says, it would be a feasible interim solution.
> >> >
> >>
> >> TUS is most emphatic on this point: An IDS is *not* the same thing as
> >> encoding. It should be considered a better-than-nothing stop-gap
> >> until something appropriate comes along (either an encoded character
> >> or a registered variation sequence). I suppose that a text in say
> >> Zhuang could use a custom font to hide the fact that most of it
> >> consists of IDSs, but in such a case Unicode explicitly warns that no
> >> operation other than display-related ones will likely work. Using an
> >> IDS in running text is a hack.
> >
> > Considering the rejected characters, "until" does not seem appropriate.
> > For such IDS is the only option. And not much of an option either
> > since very few environments can actually render it.
> >
> > <U+2FF5 U+9580 U+9F8D> ?
>
> An interesting first character <U+2FF5 U+9580 U+9F8D>, which an IDS
> parser would not find too difficult. Is this someone's name? This
> character is a good example, in that it is clearly not in the already
> encoded CJKV charcters, there are no unification issues about this.
Yes, my surname.
I mentioned it around March 2002 on this list.
You may find it in L2/07-161 (Index UTC00119) and the status is "Not to encode".
<U+2FF5 U+9580 U+9F8D> ÛÍ
T¨ky¨, Japan
This archive was generated by hypermail 2.1.5 : Tue Oct 30 2007 - 15:08:38 CST