Hello Peter,
On 2014/11/15 23:09, Peter Saint-Andre - &yet wrote:
On 11/14/14, 11:45 AM, Takahiro Nemoto wrote:
Hi, Peter-san
Thank you for your quick reply.
I think that this profile is similar to the nickname profile too.
However, even though NKFC has the benefit of increasing the
probability of comparison matching,
the aggressive normalization may create a problem. Using NKFC on some
characters may cause
changes on the character’s form and byte length that would confuse
users.
For this reason, I chose NFC and width mapping.
I don't see a compelling difference between "NFKC without width mapping"
and "NFC with width mapping", and I would strongly prefer to avoid
having two profiles here.
You got me confused here. Surely "NFKC without width mapping" and "NFC
with width mapping" differ quite a bit, namely for all compatibilitity
formatting tags (for a list, see e.g.
http://www.sw.it.aoyama.ac.jp/2013/pub/NormEquivTut/#kompabitibily_tags).
If we don't care about compatibility mappings at all, then just doing
NFC would be the simplest thing to do.
The reason why Takahiro is proposing "NFC with width mapping" is that
width differences are very well known to be ignored by users entering
text especially here is Japan. On the other hand, other compatibility
formatting categories such as <sub>, <super>, <fraction>, <circle>,
<square> and so on are visually clearly different and and therefore are
extremely rarely selected by users, if they can be input at all. For
other cases, such as <isolated>,..., these may exist in legacy
documents, but aren't produced by current input methods (read
keyboards,...).
So "NFC with width mapping" makes ample sense to me, whereas "NFKC
without width mapping" does not make any sense whatsoever in the first
place, and any profile (or whatever it's called) that used it would be
seriously flawed in my opinion and should be fixed.
Regards, Martin.
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
