- From: Greg Eck <greck@postone.net>
- Date: Wed, 21 Sep 2016 00:35:34 +0000
- To: Andrew West <andrewcwest@gmail.com>
- CC: "public-i18n-mongolian@w3.org" <public-i18n-mongolian@w3.org>
Hi Andrew, Thanks for the explanation on the definition of the MVS. I will check further with Andrew Glass. Greg >>>>> From: Andrew West [mailto:andrewcwest@gmail.com] Sent: Tuesday, September 20, 2016 11:45 PM To: Greg Eck <greck@postone.net> Cc: Jargal Badagarov <bjargal@mail.ru>; public-i18n-mongolian@w3.org Subject: Re: MVS Deficiency & Proposed Solution Hi Greg, This is certainly a worrying situation which needs to be fixed, but I am not convinced that the answer is to deprecate the MVS and encode two new characters. You state that "The problem is that the MVS carries its space internally by its definition. Therefore all through the above process, the MVS space was there." In fact, by definition MVS is a format character (general category = Cf) not a space character (general category = Zs), so it does not have an inherent space. Andrew Glass will know the answer better than me, but I do not see any reason in principle why the OpenType feature cannot be implemented in the font so that MVS only results in a space when followed by a/e alone, and behaves as if it were not there when followed by a/e + suffix. I believe that fixing the problem in the fonts will be a better, and far less disruptive solution, than encoding two new characters. Andrew >>>>>
Received on Wednesday, 21 September 2016 00:36:08 UTC