Hi, William,
I have to admit that I really haven't looked carefully at your
transformation techniques and their intended purpose. But it strikes me that
you might be re-inventing the wheel. A number of schemes exist for squeezing
wide bit patterns into narrow bit streams. UTF-8 has been adopted b
ROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, February 21, 2001 2:30 AM
Subject: Re: Perception that Unicode is 16-bit (was: Re: Surrogate space in
Unicode)
> The following statements have been made by participants in this thread.
>
> 1.
>
> A few days ago I said the
On Tue, 20 Feb 2001 10:29:17 -0800 (GMT-0800), [EMAIL PROTECTED]
wrote:
>
>On 02/20/2001 11:18:40 AM Tobias Hunger wrote:
>
>>Looks like David was quoting me. I am working on Babylon and wanted to
>make
>>clear that it is not unicode conformant as its API uses 32bit wide
>characters
>>which viola
Paul Keinänen said:
> >[86-M8] Motion: Amend Unicode 3.1 to change the Chapter 3, C1 conformance
> >clause to read "A process shall interpret Unicode code units (values) in
> >accordance with the Unicode transformation format used." (passed)
>
> While this wording makes it possible to handle any
On Tuesday 20 February 2001 19:29, [EMAIL PROTECTED] wrote:
> This is something that UTC should clean up because C1 is obsolete. In fact,
> UTC just took that action when they met a couple of weeks ago:
Wow, that's great news for me. I am currently very involved with my studies
and other project
Tobias Hunger said:
>
> Looks like David was quoting me. I am working on Babylon and wanted to make
> clear that it is not unicode conformant as its API uses 32bit wide characters
> which violates clause 1 of Section 3.1.
No longer, as Peter pointed out.
> Babylon can im-/export UTF-8/16/32
On 02/20/2001 11:18:40 AM Tobias Hunger wrote:
>Looks like David was quoting me. I am working on Babylon and wanted to
make
>clear that it is not unicode conformant as its API uses 32bit wide
characters
>which violates clause 1 of Section 3.1.
This is something that UTC should clean up because
The following statements have been made by participants in this thread.
1.
A few days ago I said there was a "widespread belief" that Unicode is a
16-bit-only character set that ends at U+. A corollary is that the
supplementary characters ranging from U+1 to U+10 are either
little-k
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 20 February 2001 17:03, you wrote:
> In a message dated 2001-02-20 06:18:34 Pacific Standard Time,
> > >into a new library called 'Babylon'. It will provide all the
> > > functionality defined in the Unicode standard (it is not Unicode bu
In a message dated 2001-02-20 06:18:34 Pacific Standard Time,
[EMAIL PROTECTED] writes:
> >With the Unicode-related functions in Prague growing out of size, I moved
> them
> >into a new library called 'Babylon'. It will provide all the functionality
> >defined in the Unicode standard (it is n
until one does extensive
reading on the website (or in the book).
Patrick Rourke
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Unicode List" <[EMAIL PROTECTED]>
Sent: Tuesday, February 20, 2001 8:37 AM
Subject: Re: Perception that Unicode is 16-bit (was: Re: Surrog
On 02/19/2001 08:05:49 PM David Starner wrote:
>With the Unicode-related functions in Prague growing out of size, I moved
them
>into a new library called 'Babylon'. It will provide all the functionality
>defined in the Unicode standard (it is not Unicode but ISO 10646 compliant
as
>it uses 32bit
On Mon, Feb 19, 2001 at 05:42:41PM -0800, [EMAIL PROTECTED] wrote:
> A few days ago I said there was a "widespread belief" that Unicode is a
> 16-bit-only character set that ends at U+. A corollary is that the
> supplementary characters ranging from U+1 to U+10 are either
> little-
A few days ago I said there was a "widespread belief" that Unicode is a
16-bit-only character set that ends at U+. A corollary is that the
supplementary characters ranging from U+1 to U+10 are either
little-known or perceived to belong to ISO/IEC 10646 only, not to Unicode.
At lea
14 matches
Mail list logo
