ISSUE-501: Unicode equivalence type non-specificity

Unicode equivalence type non-specificity

Raised by:
Addison Phillips
Opened on:


The unicodeEquivalentType parameter provides four possible parameters. Three of these (canonical, compatibility, and all) allow either C or D forms rather than specifying which shall be used. Because of the nature of what FindText is doing (finding matching code point sequences), the results may vary depending on which normalization form is chosen. The FindText API should either (a) be specific about whether the composed or decomposed sequence is used or (b) define separate terms for composed and decomposed.
Related Actions Items:
No related actions
Related emails:
  1. I18N-ISSUE-501: Unicode equivalence type non-specificity ⓟ [find-text] (from on 2015-10-16)

Related notes:

Richard Ishida, 17 Mar 2016, 12:27:14

Display change log ATOM feed

Addison Phillips <>, Chair, Richard Ishida <>, Fuqiao Xue <>, Atsushi Shimono <>, Staff Contacts
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: index.php,v 1.326 2018/10/13 17:29:51 vivien Exp $