- From: Badral S. <badral@bolorsoft.com>
- Date: Thu, 12 Nov 2015 21:20:23 +0100
- To: public-i18n-mongolian@w3.org
- Message-ID: <5644F487.6000009@bolorsoft.com>
Hi Greg, We know and we also tried to hold FVS assignments from commonly occurring to less occurring glyphs. If you remember, we also represented that we have to hold this principle and it was contradicted by Prof. Quejinzhabu in 2013 at Inner Mongolian University. So, I didn't say, that we change the current order of FVS1. I just want to improve the second or third order of FVSs, because we don't know whether FVS2 and FVS3 are really handled by the usage occurrence. The problem is that to recognise most frequently occurring glyph is easy but sorting is difficult. I think, the intention and the ultimate goal of this discussion is to give clearly defined disciplines to developers to develop fonts and to give clearly formulated principles to users where they use FVSs etc.? Please remember the idiom: "The more haste, the less speed." Badral On 12.11.2015 17:04, Greg Eck wrote: > > Hi Badral and all, > > One of our guiding principle that we have used in our discussions is > that we disturb the encoding as little as possible all the while > trying to make it at least sufficient. The assignment of FVSs from the > beginning does exhibit order, but it is idiosyncratic at times. That > is not necessarily a bad thing – it was a design decision given the > current state of font development. To try to bring in a much higher > level of order into the encoding at this point in time is probably > hopeless. I like the notions that have been brought up about assigning > the default glyph to the most commonly used glyph at a given position. > I like the thought of making the first FVS assignment (ie FVS1) to the > next-most commonly occurring glyph. But we don’t really have the > luxury of redefining things at this point. I agree that it is not the > optimal design and implementation, but it is what we have, and we need > to be happy with it. Maybe our grandsons or grand-daughters will come > up with a better solution! > > That being said, with Mr. Jirimutu starting in 1989 when laptops were > just coming to the market, with Mr. Quejingzhabu starting his design > around the same time, with Erdenechimeg starting at least by 1999, I > laud each of you for your forward thinking design that you were able > to give to this encoding with such a premature test platform. We can > always see much better in hind-sight. > > Over the weekend I will put to pen a proposal to the UTC suggesting we > include the NP (as listed at > http://r12a.github.io/scripts/mongolian/variants.html ) as our > mutually agreed upon list of FVS assignments. I am hoping that you all > will support this move. If we need further discussion, let’s do it > quickly and specifically with images of the case in point (images in > contrast to text so there is no rendering problem) so that we can > understand each other clearly. I will write more on the situation with > the U+1807, U+180A, U+1885, and U+1886 tomorrow. Hopefully we can > settle that shortly. > > Thanks, > Greg > > -- Badral Sanlig, Software architect www.bolorsoft.com | www.badral.net Bolorsoft LLC, Selbe Khotkhon 40/4 D2, District 11, Ulaanbaatar
Received on Thursday, 12 November 2015 20:20:57 UTC