L2/03-418 From: Mark Davis Re: Boundary_Neutral Property Asmus already commented on this section; that it is somewhat muddled, and should be removed. His suggestion, which I agree with, is instead to look at the differences between BN and DICP, and decide if any property changes should be made to BN on that basis. BN is currently aligned with Cf (minus, of course, the BIDI specific characters), but it might actually be more in line with the intent to align it with DICP (Note that the first differences are because we are subtracting characters from DICP, but not from Cf. Here is a listing: In Bidi_Class=Boundary_Neutral, but not in Default_Ignorable_Code_Point: U+FFF9..U+FFFB # INTERLINEAR ANNOTATION ANCHOR..INTERLINEAR ANNOTATION TERMINATOR Total: 3 Not in Bidi_Class=Boundary_Neutral, but in Default_Ignorable_Code_Point: U+001C..U+001F # .. U+00AD # SOFT HYPHEN U+034F # COMBINING GRAPHEME JOINER U+0600..U+0603 # ARABIC NUMBER SIGN..ARABIC SIGN SAFHA U+06DD # ARABIC END OF AYAH U+115F..U+1160 # HANGUL CHOSEONG FILLER..HANGUL JUNGSEONG FILLER U+17B4..U+17B5 # KHMER VOWEL INHERENT AQ..KHMER VOWEL INHERENT AA U+180B..U+180D # MONGOLIAN FREE VARIATION SELECTOR ONE..MONGOLIAN FREE VARIATION SELECTOR THREE U+200E..U+200F # LEFT-TO-RIGHT MARK..RIGHT-TO-LEFT MARK U+202A..U+202E # LEFT-TO-RIGHT EMBEDDING..RIGHT-TO-LEFT OVERRIDE U+2064..U+2069 # .. U+3164 # HANGUL FILLER U+FDD0..U+FDEF # .. U+FE00..U+FE0F # VARIATION SELECTOR-1..VARIATION SELECTOR-16 U+FFA0 # HALFWIDTH HANGUL FILLER U+FFF0..U+FFF8 # .. U+FFFE..U+FFFF # .. U+1FFFE..U+1FFFF # .. U+2FFFE..U+2FFFF # .. U+3FFFE..U+3FFFF # .. U+4FFFE..U+4FFFF # .. U+5FFFE..U+5FFFF # .. U+6FFFE..U+6FFFF # .. U+7FFFE..U+7FFFF # .. U+8FFFE..U+8FFFF # .. U+9FFFE..U+9FFFF # .. U+AFFFE..U+AFFFF # .. U+BFFFE..U+BFFFF # .. U+CFFFE..U+CFFFF # .. U+DFFFE..U+E0000 # .. U+E0002..U+E001F # .. U+E0080..U+E0FFF # .. U+EFFFE..U+EFFFF # .. U+FFFFE..U+FFFFF # .. U+10FFFE..U+10FFFF # .. Total: 6,171 In both Bidi_Class=Boundary_Neutral and Default_Ignorable_Code_Point: [\u0000-\u0008\u000E-\u001B\u007F-\u0084\u0086-\u009F\u070F\u200B-\u200D\u2060-\ u2063\u206A-\u206F\uFEFF\U0001D173-\U0001D17A\U000E0001\U000E0020-\U000E007F] Mark __________________________________ http://www.macchiato.com º% 6 ? 7 M / > & ?  M  G $ M * 0 >  / . M ¥ ----- Original Message ----- From: "Behdad Esfahbod" To: ; Cc: ; Sent: Sat, 2003 Nov 01 17:34 Subject: [bidi] Re: UAX #9 and UTR #23 > On Thu, 30 Oct 2003, Rick McGowan wrote: > > > Two new document updates are available and will be discussed at UTC next week: > > > > Proposed Update > > UAX #9 Bidi Algorithm > > http://www.unicode.org/reports/tr9/tr9-12.html > > in 3.2 Bidirectional Character Types, two lines has been added > as: > > Characters that are not supported in rendering should be given > the type BN if they have the default-ignorable code point > property. Otherwise, they should be given a property type based > on code point, as if they were unassigned characters. > > > I cannot see why should we relax this, as the current practice is > to have bidi types in a separate database from the supported > characters. And as it's saying 'should', means that we cannot do > bidi and then pass the output to the rendering engine, as now the > spec requires that BN is assigned to those unsupported > characters. I believe it just adds more glitch, and another way > to get different orders from the same logical string. > > behdad > > > Draft > > UTR #23 Character Properties > > http://www.unicode.org/reports/tr23/tr23-3.html