- From: <jrmt@almas.co.jp>
- Date: Sat, 8 Aug 2015 00:56:14 +0900
- To: "'Greg Eck'" <greck@postone.net>, <public-i18n-mongolian@w3.org>
- Message-ID: <000d01d0d129$97271690$c57543b0$@almas.co.jp>
Hi Greg, > Item#1 - new glyph needed Ok. I can compromise on this. Just because we have met this problem on some fonts. We implemented it in our font. We can change to use Ligature for this purpose. I do know that Professor Quejinzhabu have second mapping rule for HaWang Font actually. Did you know this ? I have seen his document title in some article, and wandering why we need second mapping rule ? It is means, the special font need special mapping. And what I am advising here is to handle difference. Anyway we can pass it, its impact is not big. > Item#3 - Specification of NONE in Font Comparator columns I am not totally understand what kind of situation you had faced when creating the first version of Mongolian Baiti based on the MenWenBianMa. There is a lot kind of confusing things in that book. When we refer his book we just refer which FVS is using for which form. But it is incomplete, For example, I have not find the feminine isolate GA in in his book. Sometimes I am thinking that this book have some lake the logical thinking. If use mathematical permutation, and exclude the unnecessary part it will be more complete on the structure. > What about Jirimutu's concern that the font developer is not instructed > what to do with mistakenly type <U+1820><FVS2/FVS3>? > Is it not clear in the chart, as Richard put it on August 6 > "1) The 'NotUsed' entries are implicit. You don't need to list them in the specification." > There is no mention of a FVS2 nor a FVS3, therefore the reader knows that they are not specified. > Therefore if a user types <U+1820-Isolate><FVS2> it will only be the default isolate A. > The FVS2/3 will result in nothing beyond the default 1820 form at that given position. > I hold my ground on putting NONE in the NP column where there is no specification. It seems my explanation not understandable enough. It is Ok to put None in the unspecified column. We just need one sentence instruction to how to handle the "none" defined FVS in the Variant Form Note Documentation.. For example: "None" means do nothing to the leading character and hide the FVS. I am concerning that the font acts like, if the FVS not defined, some will display the FVS or Some will delete leading character etc. This will lead same text have different display. I am not sure I can explain it clearly or not. Regards, Jirimutu ========================================================== Almas Inc. 101-0021 601 Nitto-Bldg, 6-15-11, Soto-Kanda, Chiyoda-ku, Tokyo E-Mail: <mailto:jrmt@almas.co.jp> jrmt@almas.co.jp Mobile : 090-6174-6115 Phone : 03-5688-2081, Fax : 03-5688-2082 <http://www.almas.co.jp/> http://www.almas.co.jp/ <http://www.compiere-japan.com/> http://www.compiere-japan.com/ ========================================================== From: Greg Eck [mailto:greck@postone.net] Sent: Friday, August 7, 2015 10:32 PM To: jrmt@almas.co.jp; public-i18n-mongolian@w3.org Subject: RE: FVS Assignment for A (was: New Thread - FVS Assignment MisMatch) Hi Jirimutu, Item#1 - new glyph needed It appears to me that this is a stylistic type of thing not demanding a new glyph nor FVS assignment. What you want it would seem is a means to talk about the orkhitz A/E while it is connected to a root/stem. Some styles will handle this fine without the MVS such as the image I sent earlier from Baiti. The font Jirimutu used designed the orkhitz with space at the top evidently. Other fonts such as Baiti expect the MVS to provide the space. Beyond that, and I am not being critical, this font has an attractive appearance I think, the orkhitz glyph is not designed to join the stem - there is nothing wrong with that - it is merely a design decision. You could say that the solution is just to add the new glyph to the font repertoire and substitute it for the default in the absence of an MVS. That would probably work, but you would not meet the Quejingzhabu mandate #1 which says that all glyphs must be under control - you must be able to print/control in a standalone environment. You could make the assignment of a new FVS. But the question is whether all fonts would require this glyph. Baiti does not. I imagine it would be a smaller subset which would require that glyph. I would suggest in this case the use of a variation selector such as VS01. Item#2 - noted Item#3 - Specification of NONE in Font Comparator columns I am attaching my DS01 section on U+1820 to show how I attempt to take the ambiguity out of the FVS specification. This is what I was vaguely referring to in my note to Martin Heijdra saying that I had some ideas of how to represent the white on black and black on white FVS images of the MGWBM. Let's say that the attached chart contains all information needed and see if we can prove that wrong. Let's see if it meets your concerns about communicating how to handle the FVSs that are unassigned. The U+1820 is a unique case in that we have 4 defaults as expected. Then (given that M+FVS2 -> I+FVS1) we have FVS1 defined for each of the four positions. And we do not have FVS2 or FVS3 defined at all. I+FVS1 is used as a full-fledged emotive word expressing surprise. In+FVS1 is used only after NNBSP as the beginning letter of the ablative suffix. Therefore it is used in a given, predictable context as stated in the chart. M+FVS1 is used only without context as it is an archaic form. F+FVS1 is used only in the context of the post MVS orkhitz. The chart as attached states this usage The first objective of the chart attached (as well as U1800.pdf) as I see it - is to list all glyphs associated with the given code-point. Professor Quejingzhabu has stated emphatically that he wants to be able to control the appearance of any glyph associated with a given code-point. I agree whole-heartedly. We need first of all to be able to list all 8 representative instances of the U+1820. We do that by simulating the environment around the code-point with the ZWNJ, ZWJ, and the FVS set. There is no need for the NNBSP nor the MVS here as I see it. I think Martin Heijdra would be a big fan of this idea also - is that right Martin? There is no need to use anything other than the ZWNJ, ZWJ, and the FVS set to print a standalone glyph. So, given that, the first order of the day - to be able to list, to print, to grab hold of each of the given glyph forms of the code-point U+1820, we have achieved our objective. Now, the second objective of the chart is to deal with running text. Does the chart list whether the glyph is context-dependent or FVS-dependent or both? The second item is a given. If it is specified to be listed in the presence of an FVS, then it must work with that given FVS (ie. <GivenCharacter><FVSx>). If a context is commonly used, then that should be listed somehow also - not the specific context, but at least the fact that the glyph is commonly shaped in the presence of a predictable context. Then there is the third case where a given character will use both context and FVS in running text (these are two different instances - not the same instance) to control shaping behavior. Case in point is the Final GA U+182D. Every font developer has no doubt grappled with this one. There is the default form of the right swept masculine tail. Context of a feminine word will cause the final tail to sweep to the left. However, to handle that small set of words which defy the common context for the feminine final GA, you need the FVS1 to sweep the left-ward tail back to the right; the feminine word anomalously takes the masculine right-swept tail. Looking at the Quejingzhabu documentation as described by Martin Heijdra, we see something like this. The FVS is specified in three ways - as a standard black letter on white image, black letters on white image enclosed in parenthesis, and lastly white letters on black image. The first is the standard control to allow a character to be printed in a stand-alone context. The second with the parenthesis denotes a glyph used in a somehow non-standard context - maybe a foreign word needs this glyph, possibly a compound word, possibly an archaic word needs this form. The third representation - white on black - represents a glyph which can take a context. The first example found for the white on black in the MGWBM is our character of choice in this discussion the <U+1820-Medial><FVS2>. The second example in the MGWBM is the <U+1828-Medial><FVS3> - this is the Todo medial N. The third example is the pre-MVS U+182C final undotted QA. The next four examples are all in the U+182D block. This is followed by the U+1835-Final subject of our current discussion. The next is the U+1836-Final also subject to our current discussion. The last example of white on black in Professor Quejingzhabu's documentation (in the 1820-1842 range) is the U+1838-Final loop form - the subject of an upcoming discussion. So, let the font developer beware when he/she sees the white on black in the MGWBM! The attached chart presents the same information in a different form. The Isolate variant is the standard case - no annotations as it has no context - similar to case #1 in the Quejingzhabu nomenclature. The Initial variant has a context and this is stated - not the specifics, just that it requires a context - similar to case #3 in the Quejingzhabu nomenclature. The medial variant is superscripted with a "&" to denote that it is to be used in some special class - in this case an archaic word - similar to case #2 in the Quejingzhabu nomenclature. The final variant states that it has a context - similar to case #3 in the Quejingzhabu nomenclature What about Jirimutu's concern that the font developer is not instructed what to do with mistakenly type <U+1820><FVS2/FVS3>? Is it not clear in the chart, as Richard put it on August 6 "1) The 'NotUsed' entries are implicit. You don't need to list them in the specification." There is no mention of a FVS2 nor a FVS3, therefore the reader knows that they are not specified. Therefore if a user types <U+1820-Isolate><FVS2> it will only be the default isolate A. The FVS2/3 will result in nothing beyond the default 1820 form at that given position. I hold my ground on putting NONE in the NP column where there is no specification. Greg From: jrmt@almas.co.jp [mailto:jrmt@almas.co.jp] Sent: Friday, August 7, 2015 9:07 AM To: Greg Eck <greck@postone.net>; public-i18n-mongolian@w3.org Subject: FVS Assignment for A (was: New Thread - FVS Assignment MisMatch) Hi Greg, Here I continue my discussion around the FVS assignment for U1820-A. 1. I would like to amend one more glyph for f+FVS2. Please refer following picture. I saw you sugesstion image, it is not work on handwriting font. Please check the attached image which is zoomed to big enough to see clearly. 2. I can accept the I+FVS1 assignment, I do agree with Erdenchimeg's following comment. > Re point 3, the glyph at I+FVS1 (and M+FVS2 in NSM font) is only used after NNBSP, i.e. > it is always the first letter of a word suffix/case. > Teachers of Mongolian script always refer to this as initial form, which is the basis for the coding at I+FVS1. > However, in the Unicode standard the decision was made to code it as a middle form (basically because > it appears in the middle of the word), which is why it appears at M+FVS2 in some fonts. > I think the M+FVS2 combination could be omitted, as is done in BS. The M+FVS2 form of U1820_A should be omitted. We implemented our font as this. Just because our glyph rendering basic principle listed below, there are one M+FVS2 displaying on the <http://r12a.github.io/scripts/mongolian/variants> http://r12a.github.io/scripts/mongolian/variants If there are no different variant forms for FVS2 or FVS3, we implement it same with the default form or it means ignore the FVS2 or FVS3. It is not proper to become blank. The none in NP should give definition how to handle it, otherwise each implementation goes different direction. Thanks and Best Regards, Jirimutu ========================================================== Almas Inc. 101-0021 601 Nitto-Bldg, 6-15-11, Soto-Kanda, Chiyoda-ku, Tokyo E-Mail: <mailto:jrmt@almas.co.jp> jrmt@almas.co.jp Mobile : 090-6174-6115 Phone : 03-5688-2081, Fax : 03-5688-2082 <http://www.almas.co.jp/> http://www.almas.co.jp/ <http://www.compiere-japan.com/> http://www.compiere-japan.com/ ========================================================== From: Greg Eck [mailto:greck@postone.net] Sent: Friday, August 7, 2015 2:17 AM To: jrmt@almas.co.jp; public-i18n-mongolian@w3.org Subject: FW: New Thread - FVS Assignment MisMatch Hi Jirimutu, If we limit our comments to just the 6 FVS assignments, this is what I see . . You are in agreement with my suggestions for the suggestions being put before the UTC as outlined in my reponse to Erdenchimeg. . As to the new variant at U+1820/U+1821-Final swept left with no space - would it be something like the attached? This is the sequence < U+180A >< U+180A ><U+1820> with no MVS included. Would this not do? . You have further discussion on U+182D - let's wait until we find resolution on the 6 variant FVS assignments first. . You have further discussion on U+136 - let's wait until we find resolution on the 6 variant FVS assignments first. Greg From: jrmt@almas.co.jp [mailto:jrmt@almas.co.jp] Sent: Monday, August 3, 2015 7:01 AM To: Greg Eck <greck@postone.net>; public-i18n-mongolian@w3.org Subject: RE: New Thread - FVS Assignment MisMatch Hi Greg, I have some inputs in the FVS assignment MisMatch documents. Thanks and Regards, Jirimutu ========================================================== Almas Inc. 101-0021 601 Nitto-Bldg, 6-15-11, Soto-Kanda, Chiyoda-ku, Tokyo E-Mail: <mailto:jrmt@almas.co.jp> jrmt@almas.co.jp Mobile : 090-6174-6115 Phone : 03-5688-2081, Fax : 03-5688-2082 <http://www.almas.co.jp/> http://www.almas.co.jp/ <http://www.compiere-japan.com/> http://www.compiere-japan.com/ ========================================================== From: Greg Eck [ <mailto:greck@postone.net> mailto:greck@postone.net] Sent: Monday, August 3, 2015 12:14 AM To: <mailto:public-i18n-mongolian@w3.org> public-i18n-mongolian@w3.org Subject: New Thread - FVS Assignment MisMatch We are winding down on the NNBSP discussion. Let's go ahead with another topic as attached dealing with 6 FVS assignments. The basic issue is that the current specification says to make the assignment at one position whereas the glyph is processed by OT rulings at another position. Greg
Received on Friday, 7 August 2015 15:56:42 UTC