George W Gerrity wrote:
> The problems occur first, because the code scanner can no longer be
> stateless; second, because one needs to provide an over-ride to
> higher-level layout engines; third, because it can't solve problems
> where multiple glyphs exist, whose use is highly context-dependen
George W Gerrity scripsit:
> The problems occur first, because the code scanner can no longer be
> stateless;
It can't anyway for all the complex scripts (CJKV is not really complex,
just large).
> second, because one needs to provide an over-ride to
> higher-level layout engines;
> third, bec
Thanks Mark !
That may mean IBM AIX 5 support converison between GB18030 and
Unicode, but I don't see this is a system level of support because
there is no locale names for GB18030 in the doc of AIX 5 :
http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/admnconc/locale.htm
Zh_CN S
Jane,
One of the problems is that early Unicode adopters used the 16 bit UCS-2
encoding for of Unicode. Converting to UTF-16 requires surrogate support.
Some of the GB18030 characters require this support. ICU is dedicated to
Unicode support so a lot of effort is put into ICU to keep it up to da
On Wednesday, November 13, 2002, at 12:07 AM, George W Gerrity wrote:
In an effort to unify all character and pictographs, the decision was
made to unify CJK characters by suppressing most variant forms. That
turns out to be the single greatest objection from users -- especially
Japanese -- a
Carl W. Brown wrote:
Some Unix systems adapted faster because the later Unicode adopters used 32
bit Unicode characters making the job 100 times easier. Other companies
like Microsoft took a very big gamble and implemented the code for surrogate
support into Windows 2000 based on early drafts of
Jane Liu wrote:
That may mean IBM AIX 5 support converison between GB18030 and
Unicode, but I don't see this is a system level of support because
there is no locale names for GB18030 in the doc of AIX 5 :
The GB 18030 standard requires software to be able to _read and write_ text in the GB18030
From: "Carl W. Brown" <[EMAIL PROTECTED]>
> Other companies
> like Microsoft took a very big gamble and implemented the code for
surrogate
> support into Windows 2000 based on early drafts of the Unicode standard.
If
> they had not done it this way or had guessed wrong they might not even
have
> s
Markus,
>The standard does _not_ require to _process_ internally in GB18030. It
is sufficient to have a converter and to process in Unicode, which does
contain all of >the characters.
Just curious, do you have this in writing from the China standards body?
- Michael
Markus Scherer wrote
Mark,
I think only "converter" is not sufficient. How about the following
support :
- IME (to input CJK Ext.A characters through GB18030/Unicode code)
- X-Windows fonts support.
- iconv support
- mbtowc(), mbstowcs(), mblen()...
- and so on...
You need be able to do like what you can do on Solari
APAR IY26937 does include a Zh_CN.GB18030 locale. Here is a link to the web site where it can be obtained.
http://techsupport.services.ibm.com/server/aix.fdc51 (search for fix for APAR IY26937)
Joe
Jane Liu <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/14/2002 08:59 AM
Title: Message
Hi
Unicoders,
Does
anyone have any idea what is causing this person's computer to freeze over a
"Unicode" issue. Any help will be greatly appreciated.
Magda.
-Original Message-From: barbara kolender
[mailto:[EMAIL PROTECTED]] Sent: Thursday, November 14,
This person has installed an application that is attempting to use the
Unicode version of ATL.DLL on Win9x, which will fail (this is expected).
This error would not be related to the "freeze" (it is code that causes the
load to fail right after clicking "OK" to the messagebox); the freeze might
be
Markus,
My mistake. I should have checked the docs but I thought that AIX used a 16
bit wchar_t. In any case it still takes forever to change things in an OS.
There is so much interrelated code that fixing one thing can brake another.
Carl
> -Original Message-
> From: [EMAIL PROTECTED
Markus,
> You seem to suggest that there is a problem with 16-bit Unicode.
> It does take some effort to adapt
> UCS-2-designed functions for UTF-16, but it's not "rocket
> science" and works very well thanks to the
> Unicode allocation practice (common characters in the BMP).
> Making UTF-8/32 fu
Carl W. Brown wrote:
> Converting from UCS-2 to UTF-16 is just like converting from SBCS to
> DBCS. For folks who think DBCS it is no problem. Those who went from
> DBCS to Unicode to simplify their lives I am sure are not happy.
Ken made me laugh last March by referring to this as
"... a
16 matches
Mail list logo
