diff options
| author | Ulrich Drepper <drepper@redhat.com> | 1999-12-27 20:26:55 +0000 |
|---|---|---|
| committer | Ulrich Drepper <drepper@redhat.com> | 1999-12-27 20:26:55 +0000 |
| commit | 8892c471bf1078c28adb239a4866a01356651843 (patch) | |
| tree | fb1051f6460bce44170e84bc6c1361a388c62e41 /FAQ.in | |
| parent | 01496d70ed327406aadd322c6cd83bf516920daf (diff) | |
| download | glibc-8892c471bf1078c28adb239a4866a01356651843.tar.gz glibc-8892c471bf1078c28adb239a4866a01356651843.tar.xz glibc-8892c471bf1078c28adb239a4866a01356651843.zip | |
Update.
1999-12-27 Ulrich Drepper <drepper@cygnus.com> * iconvdata/gb2312.c: Update mapping of GB 0x212c from latest Unicode tables.
Diffstat (limited to 'FAQ.in')
| -rw-r--r-- | FAQ.in | 25 |
1 files changed, 25 insertions, 0 deletions
diff --git a/FAQ.in b/FAQ.in index 61b663ce08..babca37a11 100644 --- a/FAQ.in +++ b/FAQ.in @@ -1481,6 +1481,31 @@ implemented in some old PALcodes of AlphaStations. This may cause catch these signals. Updating the firmware to a 1999 release has fixed the problem on an AlphaStation 200 4/166. +?? The conversion table for character set XX does not match with +what I expect. + +{UD} I don't doubt for a minute that some of the conversion tables contain +errors. We tried the best we can and relied on automatic generation of the +data to prevent human-introduced errors but this still is no guarantee. If +you think you found a problem please send a bug report describing it and +give an authoritive reference. The latter is important since otherwise +the current behaviour is as good as the proposed one. + +Before doing this look through the list of known problem first: + +- the GBK (simplified Chinese) encoding is based on Unicode tables. This + is good. These tables, however, differ slightly from the tables used + by the M$ people. The differences are these [+ Unicode, - M$]: + + +0xA1AA 0x2015 + +0xA844 0x2014 + -0xA1AA 0x2014 + -0xA844 0x2015 + + In addition the Unicode tables contain mappings for the GBK characters + 0xA8BC, 0xA8BF, 0xA989 to 0xA995, and 0xFE50 to 0xFEA0. + + Answers were given by: {UD} Ulrich Drepper, <drepper@cygnus.com> |