Your misunderstanding is at the highlighted statement below. Actually 0300 *is* blocked from 0061 in this sequence, because it is preceded by a character with the same canonical combining class (i.e. U+0305, ccc=230). A blocking context is the preceding combining character either having ccc=0 or having ccc greater than or equal to the character being checked.
--Ken Starting with the NFD decomposition string, we retrieve the combining classes for each character from the UnicodeData.txt file: 0061 - 0 05AE - 228 0305 - 230 0300 - 230 0315 - 232 0062 - 0 You start at the first character after the starter (0061, with ccc=0), which is 05AE. There is no primary composition for the sequence 0061 05AE, so you move on. Looking at 0305, it is not blocked from 0061, so check the primary composition for 0061 0305. There is none for that either, so move on. Looking at 0300, it is also not blocked from 0061, so check the primary composition for 0061 0300. There is a primary composition for that sequence, 00E0, so replace the starter with that, delete the 0300, and continue. The string looks like this now: 00E0 - 0 05AE - 228 0305 - 230 0315 - 232 0062 - 0 Checking 0315 and 0062, they are not blocked, but there is no composition with 00E0, so the algorithm ends with the result: 00E0 05AE 0305 0315 0062 This disagrees with what it says in the normalization tests file as listed above. The question is, did I misunderstand the algorithm, or is this perhaps a bug in the data file? Thanks, Edwin
