Reorder combining-class to better suit Arabic shadda mark-mark positioning
As reported by Khaled on the list:
"After the introduction of canonical reordering of combining marks
(commit 34c22f8
), I'm no longer able to do mark/mark substitution or
positioning for mark sequences that involve shadda as a first mark (or
most interesting sequences at least).
"After some digging, it turned out that shadda have a ccc=33 while most
Arabic marks that combine with it have a lower ccc value, which results
in the shadda being reordered after the other mark which,
unsurprisingly, breaks my contextual substitution and mkmk anchors."
See:
http://unicode.org/faq/normalization.html#8
http://unicode.org/faq/normalization.html#9
This commit is contained in:
parent
74ef81a0b0
commit
3007ffa9e5
|
@ -98,11 +98,27 @@ is_variation_selector (hb_codepoint_t unicode)
|
|||
(unicode >= 0xE0100 && unicode <= 0xE01EF)); /* VARIATION SELECTOR-17..256 */
|
||||
}
|
||||
|
||||
static inline unsigned int
|
||||
_hb_unicode_modified_combining_class (hb_unicode_funcs_t *ufuncs,
|
||||
hb_codepoint_t unicode)
|
||||
{
|
||||
int c = hb_unicode_combining_class (ufuncs, unicode);
|
||||
|
||||
/* Modify the combining-class to suit Arabic better. See:
|
||||
* http://unicode.org/faq/normalization.html#8
|
||||
* http://unicode.org/faq/normalization.html#9
|
||||
*/
|
||||
if (unlikely (hb_in_range<int> (c, 27, 33)))
|
||||
c = c == 33 ? 27 : c + 1;
|
||||
|
||||
return c;
|
||||
}
|
||||
|
||||
static inline void
|
||||
hb_glyph_info_set_unicode_props (hb_glyph_info_t *info, hb_unicode_funcs_t *unicode)
|
||||
{
|
||||
info->general_category() = hb_unicode_general_category (unicode, info->codepoint);
|
||||
info->combining_class() = hb_unicode_combining_class (unicode, info->codepoint);
|
||||
info->combining_class() = _hb_unicode_modified_combining_class (unicode, info->codepoint);
|
||||
}
|
||||
|
||||
HB_INTERNAL void _hb_set_unicode_props (hb_buffer_t *buffer);
|
||||
|
|
Loading…
Reference in New Issue