Fix#11.
The algorithm for composition of Hangul Jamo is:
- L (choseong jamo) + V (jungseong jamo) = LV (syllable block)
- LV (syllable block) + T (jongseong jamo) = LVT (syllable block)
However, the LV and LVT syllable blocks are intermingled in the unicode
block. In particular, for each pair LV, you will first see the syllable block
LV, followed by syllable blocks for LVT for each T. The LV+T
composition was a simple addition of offsets.
Our algorithm did not ignore the LVT syllable blocks, which meant that
LVT+T would just offset further and produce an unrelated syllable block.
By ensuring that the `S_index` is a multiple of `T_count`, we filter
for only LV syllable blocks (which occur every `T_count` codepoints in
the S block)
It’s not that useful, its input being all within ASCII and unaffected by normalization,
and it sets of bad example of `char.to_lowercase().next()`,
ignoring the rest of the `ToLowercase` iterator.
This enables not allocating memory for intermediate results
in algorithms like this part of Unicode’s [*canonical caseless matching*](
http://www.unicode.org/versions/Unicode7.0.0/ch03.pdf#G34145 ):
```rust
nfkd(default_case_fold(nfkd(default_case_fold(nfd(input)))))
```
This commit imports update to regexes in `load_properties()`,
d25c39f86568a147f9b7080c25711fb1f98f056a in rust-lang/regex
Does not result in any changes to tables.rs, but could if
published tables are updated in the future.
Simon Sapin