Re: [Afpfs-ng-devel] precompose and decompose
Status: Alpha
Brought to you by:
alexthepuffin
From: HAT <ha...@fa...> - 2008-03-30 16:59:30
|
Hi. > The resulting table was further checked against: > http://developer.apple.com/technotes/tn/tn1150table.html > > and decompositions not marked "illegal" in tn1150table were removed from > the result. The tn1150table is based on Unicode 2.x (Mac OS X 10.1 and earlier). Unicode 2.x has no concept of "ordering". Mac OS X 10.2 and later are based on Unicode 3.2. Recent Leopard is based on Unicode 4. The character has increased. Maybe, Mac OS X 10.6 will be based on Unicode 5.x. I think that afpfs-ng should use newest Unicode. At present, latest version is 5.0.0. > Please let me know, if there is a newer version of the unicode > decomposition table for HFS Plus. Yes, newest version is 5.0.0. However, it's not necesary to compare it with the tn1150table. > Your suggestion (from your first message) to change the internal > character representation in lib/unicode.c from UCS2 to UCS4 absolutely > makes sense Ok. > although there are currently no decompositions in the range > > U+010000 used by HFS Plus that I'm aware of. Mac OS 10.5.2 Leopard support the following decomposition. 0x1D15E, 0x1D157 0x1D165 MUSICAL SYMBOL HALF NOTE 0x1D15F, 0x1D158 0x1D165 MUSICAL SYMBOL QUARTER NOTE 0x1D160, 0x1D15F 0x1D16E MUSICAL SYMBOL EIGHTH NOTE 0x1D161, 0x1D15F 0x1D16F MUSICAL SYMBOL SIXTEENTH NOTE 0x1D162, 0x1D15F 0x1D170 MUSICAL SYMBOL THIRTY-SECOND NOTE 0x1D163, 0x1D15F 0x1D171 MUSICAL SYMBOL SIXTY-FOURTH NOTE 0x1D164, 0x1D15F 0x1D172 MUSICAL SYMBOL ONE HUNDRED TWENTY-EIGHTH NOTE 0x1D1BB, 0x1D1B9 0x1D165 MUSICAL SYMBOL MINIMA 0x1D1BC, 0x1D1BA 0x1D165 MUSICAL SYMBOL MINIMA BLACK 0x1D1BD, 0x1D1BB 0x1D16E MUSICAL SYMBOL SEMIMINIMA WHITE 0x1D1BF, 0x1D1BB 0x1D16F MUSICAL SYMBOL FUSA WHITE 0x1D1BE, 0x1D1BC 0x1D16E MUSICAL SYMBOL SEMIMINIMA BLACK 0x1D1C0, 0x1D1BC 0x1D16F MUSICAL SYMBOL FUSA BLACK At present, the glyphs of these characters do not exist. However, I think that it is necessary to support for the future. > Will you be able (and willing ... ;-) ) to do the rewrite? I might do > it as well, but am not sure when I will find the time to actually do so. It's possible. But I do not understand all of source. Is it the following files that use UCS2 as internal code? codepage.c unicode.c unicode.h > If you have a patch, I will help with the testing, though. First of all, I wrote a sample header file. This is based on Unicode 5.0.0. -- HAT |