Closed Bug 102252 Opened 23 years ago Closed 23 years ago

Add CS Styles for Ethiopian/Eritrean Languages

Categories

(Core :: CSS Parsing and Computation, enhancement, P2)

enhancement

Tracking

()

CLOSED FIXED
mozilla0.9.9

People

(Reporter: yacob, Assigned: jshin1987)

References

()

Details

(Whiteboard: need review)

Attachments

(6 files, 1 obsolete file)

From Bugzilla Helper: User-Agent: Mozilla/4.7 [en] (X11; U; Linux 2.2.13-7mdk i686) BuildID: 20010927 This is a feature request for support of ordered list styles used in Ethiopic script by Ethiopian and Eritrean languages. Reproducible: Always Steps to Reproduce: 1. view a web page with an am_ET locale setting. 2. n/a 3. Actual Results: appears in english style Expected Results: Amharic style is requested I've put together some documentation on how ordered lists are expected to work here: http://www.ethiopic.org/Collation/OrderedLists.html An Unicode 3.0 compliant font is required to read the html file, a font with Ethiopic and Roman chars that is suitable is here: http://www.senamirmir.com/download/jiret.zip
QA Contact: ian → momoi
Status: UNCONFIRMED → NEW
Ever confirmed: true
Jungshik, can you help with this since you are faimliar with what should be included in the patch via your experience with the Korean addition? I guess what we should implement is 2 different styles under Ethiopian list styles. -moz-ethiopic-halehame -moz-ethiopic-abegede Another issue raised is a more general one. Jacob raised this issue at ftang/yokoyama/momoi's presentation of the XML & CSS presentation at Unicode Conf #19 the other day. That is, currently, we append a "period" to the number no matter what the language is. Apparently this is not correct and we need to accommodate different punctuations here. In the case of Ethiopic, the above document by Jacob suggests the following: "Dot (U+002E) is not the normal punctuation following the counter character. Either U+1366 or "/" (U+002F) should be used instead, configuration through a style sheet would be desirable." We probably should have another bug to deal with this latter issue. Who should get this other bug?
Actually, Jacob raises a 3rd issue in his document, i.e. that of the role played by locales in this particular case. Upon first reading, supporting it seems rather hard to do. So initially, we may have to be satisfied with the Ge'ez Set. Then as time allows, add additional support for punctuation, and then locale distinctions if that is feasible.
In addition to the two alphabetic style lists (starting with Ge'ez is the right thing to do) the numeric style should also be an option. There is a link from the top of the spec page posted earlier that details the issue. An algorithm in C can be found here: http://www.ethiopic.org/Numerals/ArabicToEthiopic.c -moz-ethiopic-numeric would be appropriate.
I'll take a look at it later this week.
> That is, currently, we append a "period" to the number no matter > what the language is. Apparently this is not correct and we need > to accommodate different punctuations here. I think this is a misimplementation of CSS2. No matter what language/locale is, I think nothing should be appended to the number. It should be left for CSS authors to control. For example, the following is taken from CSS2 spec: <STYLE type="text/css"> LI:before { display: marker; content: counter(mycounter, lower-roman) "."; counter-increment: mycounter; } </STYLE> This would yield : i. first item ii. second item iii. third item If Mozilla supports this, it's trivial to customize the punctuation mark.
> I think this is a misimplementation > of CSS2. No matter what language/locale is, > I think nothing should be appended to the number. > It should be left for CSS authors to control. Thanks! In that case, let me look into this and come up with an appropriate bug.
ftang, can you r= this? Do we also need sr= ?
Whiteboard: need review
Attachment #54015 - Attachment is obsolete: true
Daniel and Kats, can you look at the screenshot and see if there's anything wrong? Frank and David, Can you review my patch?
The sample html file has the following style spec. to make the punctuation after 'marker' to follow Ethiopian convention. LI:before { display: marker; content: counter(counter) "\001366" counter-increment: counter; } However, that does not work at the moment in Mozilla. If there's no bug filed for CSS2 'before' and 'after' support, I'm gonna file one.
> However, that does not work at the moment in Mozilla. > If there's no bug filed for CSS2 'before' and 'after' > support, I'm gonna file one. pseudo elments, :before and :after are already supported. So your example does not work, either the problem is isolated to this type of example, or there is a problem in the way you wrote it. I'll look at it later. Maybe dbaron knows the answer.
BTW, should it not be the following? LI:after { ... ..}
I'm not setup to build mozilla presently, but reviewing the screen shot it looks great! I'm smiling ear-to-ear this morning :-))))))) The top half of the sample web page appears to be cut off though in the screen shot, can another be posted with the top half?
No, it should be 'before' :-) 'Before' and 'after' are relative to the principal box containing each listed item. The following html snippett ---------- ..... <style type="text/css"> LI: before { display: marker; content: "(" counter(counter) ")" ; counter-increment: counter; } LI: after { display: marker; content: "END"; } </style> <ol> <li> The first item <li> The second item <li> The third item </ol> ...... ---------- should be rendered as below: (1) The first item END (2) The second item END (3) The third item END -------------- As to whether '.' should follow numbers or not by default, I'm not so sure now as I was. HTML 4.01 spec doesn't have anything to say about it (perhaps on purpose). Logically it appears make sense that nothing should be added other than what the author of the document specifies via CSS. In addition, CSS2 spec (section 12.6) has the following example to illustrate how to add '.' after numbers. This implies that '.' should not be added automatically. ------------ For instance, the following example illustrates how markers may be used to add periods after each numbered list item. This HTML program and style sheet: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> <HTML> <HEAD> <TITLE>Creating a list with markers</TITLE> <STYLE type="text/css"> LI:before { display: marker; content: counter(mycounter, lower-roman) "."; counter-increment: mycounter; } </STYLE> </HEAD> <BODY> <OL> <LI> This is the first item. <LI> This is the second item. <LI> This is the third item. </OL> </BODY> </HTML> should produce something like this: i. This is the first item. ii. This is the second item. iii. This is the third item. ----------- However, this may not be the best course of action for UA implementors to take because so many html authors have taken it granted that '.' follows numbers in <OL> list that a sudden change may take them by surprise. Perhaps, what's to be done is supply the locale-dependent (per Yacob's suggestion) default when there's no 'before pseudo-element' specified for marker. Otherwise, just do what the authors want. If one wants bare numbers, (s)he can have something like this in her/his css. LI:before { display: marker; content: counter(mycounter); counter-increment: mycounter; } By the way, 'before' and 'after' pseudo-elements don't appear to work in the marker box of list although they work with others. I took an example from CSS2 spec. and put it up at http://jshin.net/moztest/css.marker.html so that you can test it yourself.
We support :before and :after but we don't support 'display: marker'. 'display: marker' and its use with :before may be deprecated in future versions of CSS since it doesn't sufficiently describe formatting of list items, so I'm not sure whether it's worth working on supporting it unless what we really work on is coming up with a better proposal for CSS3.
I just checked the new screen shot and it was perfect. I looked back at the original one with the numeric list example and all sequences were perfect except for "4723402" which should have become the ethiopic sequence: (4)(100)(10,000)(70)(2)(10,000)(30)(4)(100)(2) The (70) was missing. I'll check my other algorithms against this number and look for a bug in the pseudo code.
Yacob, thank you for checking. You don't have to worry about 4723402. In my test html, I made a mistake. I should have had the following <li value="4723402"> 4723402 instead of <li value="4023402"> 4723402 As you can see, the label and the actual numerical value were different and that's why '70' was missing in my screenshot. Now with this typo fixed, everything looks as it should be as far as I can tell.
David, Thank you for your info. about status of 'marker' in CSS standard. I'm not sure if it's worth working on, either. If CSS2 has been supported by Mozilla long enough (this is subjective, but say a few years), I would say even 'to-be-depreciated' elements have to be supported. ... Incidentally, what would you do if you want a set of new list-style types to be added to upcoming CSS3 standard? I sent an email to CSS mailing list @W3 about two Korean list-style I added earlier this year, but I haven't had any response. Yacob, you may also want to write to CSS mailing list to add these new list-type to CSS3 if that's a good way.
> Yacob, you may also want to write to CSS mailing list to add > these new list-type to CSS3 if that's a good way. jungshik, we have other styles we want to add, too. I think it might be better if we submit a unified proposal selecting a number of styles out of the -moz- type pool in Mozilla code.
> jungshik, we have other styles we want to add, too. I think > it might be better if we submit a unified proposal selecting > a number of styles out of the -moz- type pool in Mozilla code. I agree. It would be nice if we can get them included in CSS3.
OK. Let me mail a msg to a few people and see what we can do to get a proposal to W3C CSS WG. (I'll write to you jungshik.)
I remember multilingual computing have a paper about Ethiopic script and it mention the number. I will try to find it.
> I remember multilingual computing have a paper about Ethiopic script and it > mention the number. I will try to find it. I read the article, too :-) As mentioned in my patch, Unicode 3.0 section 11.1 has the same info. as Daniel's web page (not that I didn't believe Daniel). If my memory serves me well, MLC article is in agreement with both. One thing I didn't implement,though, is that 'thousand' marker which Unicode 3.0 mentions is used in some cases. > OK. Let me mail a msg to a few people and see what we can do to > get a proposal to W3C CSS WG. (I'll write to you jungshik.) Thank you :-)
> (not that I didn't believe Daniel). heh, actually I wrote the article and I don't believe myself :) The MLC copyright policy wasn't clear to me so I obfuscated the algorithm for publication. Unfortunately I also broke it for some special cases that I discovered too late. The version I have online I believe is correct, unless there's some typo I'm not seeing. I checked the suspect number with my perl implementation (available as a link from the bottom of the web article, it follows the algorithm almost exactly) and it converted just fine. I examined Jungshik's implementation and couldn't catch a problem with it. I wonder if the font is maybe broken for "70" or if there is some other display problem? Jungshik, can you try an <li value="70"> to see if anything appears?
Jungshik, sorry! Too much mail today :P I just read your comment about the typo in your <li>. So my concern for the broken font is invalid now and the algorithm is fine. In fact your version is more effecient and I'll update my own C implementation with it ;) Kat, let me know if there is anything I can provide to make the case for CSS3 support.
RCS file: /cvsroot/mozilla/content/shared/public/nsCSSKeywordList.h change look ok RCS file: /cvsroot/mozilla/content/shared/src/nsCSSProps.cpp change look ok RCS file: /cvsroot/mozilla/layout/base/public/nsStyleConsts.h change look ok RCS file: /cvsroot/mozilla/layout/html/base/src/nsBulletFrame.cpp change: only format issue. if ( xxx ) { should be if (xxx) { - no space between ( and xxx and change line for { otherwise r= change that and ask sr=
I think there are a couple of problems that should be addressed. 1. Daniel's paper at http://www.ethiopic.org/Collation/OrderedLists.html overlooks the characters \u1248, \u1258, \u1288, \u12B0, \u12C0, and \u1310 in all the listing. I don't blame him for that because these characters are overlooked in general use for sorting although they have been part of the writing system. After Unicode 3.0 things are different; sorting order is clearly set. The question now is can we have a listing order that is different from that of Unicode's? I am not sure who has the last say on this, but something must be done before the current work is done. 2. Which Halehame and Abegede (Abugida)? Daniels's papar presents three Halehame's orders and I do understand why that is so, but Jungshik's screen shots (id=54072) list order is based on one of them--Ge'ez. I am be erring here, but the listing order should be based on Ethiopic first characters as Unicode because Unicode's listing order is a superset of the other two. My observation is strictly based on the screen shot indicated above. 3. Use of Abegede (Abugida) There are very limited works that made use of Abegede in the past. The de facto standard is Halehame. Abugida implementation would be to historical value which is a nice thing to have. Thank You, -abass ~~~~~~~~~~~~~~~~~~~~~
> 1. Daniel's paper at > > http://www.ethiopic.org/Collation/OrderedLists.html > > overlooks the characters \u1248, \u1258, \u1288, > \u12B0, \u12C0, and \u1310 in all the listing. > I don't blame him for that because these characters > are overlooked in general use for sorting although > they have been part of the writing system. After > Unicode 3.0 things are different; sorting order is > clearly set. Sorting simply should not be confused with counting. Unicode as a sort order is by no means required, it is the lazy way to go of course, but a little effort can correct Unicode's obvious errors. > The question now is can we have a listing order > that is different from that of Unicode's? I am > not sure who has the last say on this, but > something must be done before the current work > is done. Tradition should be the only deciding factor here. You are suggesting to define something new vs working with what is already well established. Unicode provides a set of characters only, how you work with them is still up to you. Have you honestly ever seen or used the characters above in an ordered list context? Applying them in this way would only confuse people. Society shouldn't have to be re-educated because Unicode is doing something a certain way. Rather, developers should be educated in the expectations of society. > 2. Which Halehame and Abegede (Abugida)? > Daniels's papar presents three Halehame's orders > and I do understand why that is so, but Jungshik's > screen shots (id=54072) list order is based on one > of them--Ge'ez. I am be erring here, but the > listing order should be based on Ethiopic first > characters as Unicode because Unicode's listing > order is a superset of the other two. My observation > is strictly based on the screen shot indicated > above. I believe this is the locale issue. > 3. Use of Abegede (Abugida) > There are very limited works that made use of > Abegede in the past. The de facto standard is > Halehame. Abugida implementation would be to > historical value which is a nice thing to have. The Abugida order is actually a bit different from Abegede but are often confused as the same. Abugida, in the Ge'ez column, is the Hebrew order with the 4 extra letters of Ge'ez following at the end. Your KWK dictionary has some explanation. I debated suggesting Abugida as well but realistically I can't say that I have encountered its use in order lists. Abegede is an alphabetic order, Abugida is fundamentally different in purpose. Rather than elaborate here, a comparison tables and some further explanation are below: http://www.ethiopic.org/Collation/ http://www.ethiopic.org/Numerals/Numerology.html
> 1. Daniel's paper at > > http://www.ethiopic.org/Collation/OrderedLists.html > > overlooks the characters \u1248, \u1258, \u1288, > \u12B0, \u12C0, and \u1310 in all the listing. > I don't blame him for that because these characters > are overlooked in general use for sorting although > they have been part of the writing system. After > Unicode 3.0 things are different; sorting order is > clearly set. : Sorting simply should not be confused with counting. I hope you don't take me for that! : Unicode as a sort order is by no means required, it is : the lazy way to go of course, but a little effort can : correct Unicode's obvious errors. I tend to appreciate uniformity! Certainly, the script does offer that. > The question now is can we have a listing order > that is different from that of Unicode's? I am > not sure who has the last say on this, but > something must be done before the current work > is done. : Tradition should be the only deciding factor here. You : are suggesting to define something new vs working with : what is already well established. Unicode provides a set : of characters only, how you work with them is still up to : you. Have you honestly ever seen or used the characters : above in an ordered list context? a) We can debate the tradition factor, but it shouldn't be just between you and me. In other words, there should be some transperency for the sake of all. I am gratefull to Yung-Fong becuase if he has not posted this development on a number of lists, you know what I am talking about. b) There are discripancies in the use of listing order based on alphabet. Unlike you, I don't regard Unicode as just a "set of characters.." only, but a set of characters with unique order. Following that order in every way possible is good for everyone. Yes, I know there are language related issues, but I strongly believe that they be addressed with qualified falks in the area. c) No, I haven't seen any list order using those characters which I mentioned above, but that was before Unicode. > 3. Use of Abegede (Abugida) > There are very limited works that made use of > Abegede in the past. The de facto standard is > Halehame. Abugida implementation would be to > historical value which is a nice thing to have. : The Abugida order is actually a bit different from Abegede : but are often confused as the same. Abugida, in the Ge'ez : column, is the Hebrew order with the 4 extra letters of Ge'ez : following at the end. Your KWK dictionary has some explanation. : I debated suggesting Abugida as well but realistically I : can't say that I have encountered its use in order lists. : Abegede is an alphabetic order, Abugida is fundamentally : different in purpose. I went beyond KWK's works and looked at a dictionary titled "Comparative Dictionary of Geez" by Prof. Leslau and I quote: "KWK's dictionary is arranged in the order of the abugida, that is, of the Hebrew alphabet. The arrangement is as follows: `, b, g, d, h, ..., p.[p. XI]" I even checked "The World writing Systems" edited by Peter T. Daniels and William Bright. There Dr. Getatchew haile writes, after commenting on the order of the Ethiopic, "(...In certain religious contexts, the North Semitic order--called abugida, from the first four consonants and the first four "orders"--which is know from the acrostic poems in the Ge'ez translation of the Hebrew Bible, is also found.)[p.570]" There seems to be two variation of Abugida becuase the one that I learned when I was kid is different from the KWK's, which you refer to as "Abegede". In fact, KWK's abugida is not limited to the original Ge'ez, it also includes those characters that were included for Amharic. Thank You, -abass ~~~~~~~~~~~~~~~
> a) We can debate the tradition factor, but it shouldn't > be just between you and me. In other words, there > should be some transperency for the sake of all. To this end the Ethiopian Computers Standards Authority was informed prior to the submission of the bug report. > There seems to be two variation of Abugida becuase the one > that I learned when I was kid is different from the KWK's, Consider the context that the Abugida table is taught in. "Abugida" the term is used very loosely. The Ethiopian Abugida order also mirrors the north semetic order up to the last 4 entries. "Abegede" is more precise and is unique to Ethiopia, I use "Abegede" to avoid confusion with "Abugida". KWK presents both systems, check the order of the dictionary itself, that is the order that the letter chapters are presented in, and see that it is not the north semetic sequence. > In fact, KWK's abugida is not limited to the original Ge'ez, it also > includes those characters that were included for Amharic Such are presented in my ordered list tables, this is also areturn to the issue of locales.
> a) We can debate the tradition factor, but it shouldn't > be just between you and me. In other words, there > should be some transparency for the sake of all. : To this end the Ethiopian Computers Standards Authority : was informed prior to the submission of the bug report. The operative term "informed" makes me feel what is next. > There seems to be two variation of Abugida becuase the one > that I learned when I was kid is different from the KWK's, : Consider the context that the Abugida table is taught in. : "Abugida" the term is used very loosely. The Ethiopian : Abugida order also mirrors the north semetic order up to : the last 4 entries. "Abegede" is more precise and is unique : to Ethiopia, I use "Abegede" to avoid confusion with "Abugida". : KWK presents both systems, check the order of the : dictionary itself, that is the order that the letter : chapters are presented in, and see that it is not the : north semetic sequence. 1. Since you are using KWK to defend what you are doing, may be you would have a second thaught after reading the quote below. KWK writes, after narrating how Halehame replaced Abugida, (translation is mine) "... Making a distinction from "Halehame", they refer to the order using its original name Abegede or Abugida. Abugida's arrangement while keeping the first order characters intact, it inter-mixes the one from the second order to the seventh. [p. 33]" He also uses the term "Abegede" for the arrangement of Ethiopic script prior to "Halehame". He has two Abugida tables that are related to the discussion at hand--one is based on the Ge'ez (Ethiopic) language while the second one is on Amharic. Since Amharic uses more base-characters than Ge'ez (Ethiopic), the difference has to be there. 2. DTW, in his land mark "Amharic Dictionary", uses the second table (the one based on Amharic) from KWK. And when he discusses about the entries arrangement of his dictionary at page 6, he refers to the order as "Abegede". Here is the definition of "Abegede" at page 73 (translation mine) "Classic/old Ge'ez script used before 'Selama'" Here is the definition of "Abugida" at page 74 (translation mine) "...A table with an intact order of base-characters and diagonally arranged extended characters." A close examination of the DTW writings testifies that both "Abegede" and "Abugida" are in the same family of order. 3. In conclusion, what we have is the following: + ---- Ge'ez | Halehame --------+ ---- Amharic, Tigregna, Oromo, ... (Unicode) | + ---- Others + ---- Ge'ez | *Abugida --------+ ---- Amharic | + ---- Others * Abugida is a popular term, but if there is a need to replace it by "Abegede", then consensus must be built. Thank You, -abass ~~~~~~~~~~~~~~~~~~~
> 1. Since you are using KWK to defend what you are doing, > may be you would have a second thaught after reading the KWK's dictionary was a common reference that I knew we both had. Both Abegede and Abugida orders can of course be found outside his work. No more significant work has made use of the Abegede order however, but then few works but dictionaries are themselves sorted. > He has two Abugida tables that are related to the discussion > at hand--one is based on the Ge'ez (Ethiopic) language while > the second one is on Amharic. Since Amharic uses more > base-characters than Ge'ez (Ethiopic), the difference has > to be there. The Amharic table on page 40 is NOT in the Abugida order. Harm, Peyt, Sepa and Psa are mixed in the sequence and not appearing at the end. The issue at hand, I thought, was not the collection of characters that are to be used in a list order, of course that changes with the language, but rather the sequence of the list order itself. In which case the two tables to consider are the two Ge'ez tables on pages 34 and 35. Look at their difference carefully, the first indicator of the difference is that Harm follows Hawt on the ninth row under the first ("Abegede") table on page 34. KWK is careful to label the second table as "Abugida" and not the first. Abugida is the order used to map Hebrew names and Hebrew's numbering system from which Ethiopic names and numerals are derived. See the top of page 41 for this, then look in the middle of page 41 and we're back to Abegede sequence, Harm follows Hawt. Names are shown on page 33. > Here is the definition of "Abegede" at page 73 (translation > mine) > "Classic/old Ge'ez script used before 'Selama'" Amen! Yay for Ge'ez! Lets be careful not to loose this unique aspect of Ethiopian cultural heritage. What is Selama? Aba Selama? That would be insightful.. > 2. DTW, in his land mark "Amharic Dictionary", uses the second > table (the one based on Amharic) from KWK. And when he Again he wisely chose the "Abegede" sequence. This is not so suprising as DTW is also the editor of KWK's dictionary. > Here is the definition of "Abugida" at page 74 (translation > mine) > "...A table with an intact order of base-characters > and diagonally arranged extended characters." Intact in the Hebrew / North Semetic sense, absolutely, undisputably, entirely necessary as per Abugida's application. > A close examination of the DTW writings testifies that > both "Abegede" and "Abugida" are in the same family of > order. Same family yes, of course but the Ethiopian usage of Abegede differs from Abugida. so lets talk about usage then. There are other orders that Ethiopic has been presented in, I can think of two used for primary school education, but they are not later used for collation in any way, that was never their purpose. So where is a book where the Abugida sequence is used in collation? I have not found one. KWK's dictionary however is presented unmistakably in Abegede collation. Lets assume he and DTW knew the difference and that thier decision was not a mistake. So my conclusion is.... What I would propose, what I had wished to do at the beginning but could not justify (back up with usage evidence), is to have both "Abegede" and "Abugida" options. I think you've demonstrated that there will be a demand for it. "Abugida" is more popularly known, that much is certain, "Abegede" appears to have had a more acedemic usage. Options are *good* :)
> So my conclusion is.... > What I would propose, what I had wished to do at the beginning but could > not justify (back up with usage evidence), is to have both "Abegede" and > "Abugida" options. I think you've demonstrated that there will be a demand > for it. "Abugida" is more popularly known, that much is certain, "Abegede" > appears to have had a more acedemic usage. Options are *good* :) I am sorry that I have to disappoint you now. In most part of your reply to my messages, there is nothing, but incoherent opinions. Not once, you have presented a reference what linguists, semitic study scholar, or writers have to say about Abugida/Abegede. You keep pointing to KWK's tables, but you cannot event site any passage what he has to say about them. I wish you had given him (or others) the credit he properly deserve when you use his work on your paper. Let me do this one last time, Abugida/Abegede is used to refer to one class of order. KWK offers this order with respect to Ge'ez and Amharic. If you think otherwise, then show it with evidence. As the to the demand for Abugida/Abegede ordering list, would you please show any acedemic work/usage in the last 50 years? Please don't take me wrong, having Abugida/Abegde as ordering list is good. -abass ~~~~~~~~~~~~~~~~~~~~~~~~~
> I am sorry that I have to disappoint you now. In most part of > your reply to my messages, there is nothing, but incoherent > opinions. Not once, you have presented a reference what linguists, Incoherence is relative to the capability of the reader. You have not cited what you've found to be incoherent. > semitic study scholar, or writers have to say about Abugida/Abegede. > You keep pointing to KWK's tables, but you cannot event site any > passage what he has to say about them. I wish you had given him you have already done so! > (or others) the credit he properly deserve when you use his work > on your paper. KWK did not invent either. He just applied Abegede. In the paper that the feature request tables come from, KWK among others are creditted. > Let me do this one last time, Abugida/Abegede is used to refer > to one class of order. KWK offers this order with respect to One class of order, one family of order, but not the same order. I've pointed this out repeatedly, you have always avoided the issue and continue to imply that they are the same. > Ge'ez and Amharic. If you think otherwise, then show it with > evidence. You've had the evidence in your hand, I've given you the page numbers and the tables, you avoid the discussing this evidence. You have not even addressed the fact that KWK applied Abegede as the alphabetic order of the dictionary. Abegede and Abugida do not stop at Amharic, I do have evidence of this. > As the to the demand for Abugida/Abegede ordering list, would you > please show any acedemic work/usage in the last 50 years? Academic work is pleantiful, usage is somewhat weaker, mostly for reprinting old materials of course. Academic work does not apply the order though, just notes its earlier usage. An example is: Yimam, Baye, "Ethiopian Syllabaries", The Encyclopedia of Language and Lingustics Volume 3, p 1149-1151, Pergamon Press, NY Unfortunately my photocopy doesn't have a year, but it is older than 1977 which is the oldest reference that Dr Baye cites. He also presents Sabean script in Abegede order (not Abugida) which I thought was peculiar. Review Tekle-Tsadik Mekuriya's work also. In the early '90s there was a movement to return to Abegede again and some new work was produced, at least one Amharic dictionary using the order (I may even have a copy). The Soviets pushed the system also in the 70s.
> semitic study scholar, or writers have to say about > Abugida/Abegede. You keep pointing to KWK's tables, but you > cannot event site any passage what he has to say about them. > I wish you had given him : you have already done so! If I did, I don't think it has landed near you. A few mails ago I quoted Prof. Leslau, a prominent scholar on a number of Ethiopian languages, saying that he refers to KWK's dictionary arrangement as Abugida, but you implicitly said that is not so. I also quoted Dr. Getachew Haile, another prominent Semitic Study scholar, refering to Abugida as another ordering system compared to Halehame, but that doesn't seem to sink-in! Since you were fencing yourself with KWK's tables, but not his observation and analysis, I referred you to a statement where he writes that the ordering system was called as Abegede or Abugida. Once again, this was not good enough for you. What is left, unless you have something else to show, is your opinion--interpretation of KWK's tables. You wouldn't accept that as there is a difference between "Ge'ez-Halehame" and "Amharic-Halehame" ordering, there is also that difference in Abugida/Abegede. Thus, KWK's dictionary arrangement can be attributed to Abugida/Abegede. The names Abugida and Abegede, with respect the script ordering, are interchangeable. Period! > (or others) the credit he properly deserve when you use his work > on your paper. : KWK did not invent either. He just applied Abegede. In the : paper that the feature request tables come from, KWK among : others are creditted. The issue isn't if KWK invented it or not, it is whether you used/copied his work and failed to give him the credit, or not. I might be wrong, but the page you sited here mention no KWK or DTK. Unfortunately, such misdeed is not new! > As the to the demand for Abugida/Abegede ordering list, would you > please show any academic work/usage in the last 50 years? : ... : Yimam, Baye, "Ethiopian Syllabaries", ... : Review Tekle-Tsadik Mekuriya's work also. ... : In the early '90s there was a movement ... By far this isn't an impressive list; don't you think so? -abass ~~~~~~~~~~~~~~~~~~~~
> arrangement as Abugida, but you implicitly said that is not > Ethiopian languages, saying that he refers to KWK's dictionary > arrangement as Abugida, sorry if I wasn't explicit when I said that "Abugida" is a term used very loosely. Obviously this is the case in Leslau's usage since the dictionary is not in Abugida order. > so. I also quoted Dr. Getachew Haile, another prominent Semitic > Study scholar, refering to Abugida as another ordering system > compared to Halehame, but that doesn't seem to sink-in! This is still loose usage, did he go on to present what he refers to as "Abugida" or is it left unqualified? > opinion--interpretation of KWK's tables. You wouldn't accept > that as there is a difference between "Ge'ez-Halehame" and > "Amharic-Halehame" ordering, there is also that difference in How is that I have not accepted it and at the same time I have presented it, even requested the difference be recognized, in this feature request? > Since you were fencing yourself with KWK's tables, but not > his observation and analysis, I referred you to a statement > where he writes that the ordering system was called as > Abegede or Abugida. Once again, this was not good enough for > you. It was good enough, it was very good enough. The are used interchangeably, he notes that indeed. The two definitions you posted indicate that the two are not one. What more need I do? > attributed to Abugida/Abegede. The names Abugida and Abegede, > with respect the script ordering, are interchangeable. Period! As per the loose usage that a layman will employ they are interchangeable, but it is not a precise way to discuss them. I have qualified my usage of the terms as I apply them to the two orderings. I have labeled my own tables accordingly. If you have another term to substitute for what I'm referring to as "Abegede" please inform us. Are you mearly requesting that the proposed order, the order of the dictionary, be referred to as "Abugida"? That the list type be named "-mox-ethiopic-abugida" instead of "-moz-ethiopic-abegede"? Please answer this and settle the matter. Which order do you want to see implemented? Is it as per the table on page 34 or 35 of KWK's dictionary? See, isn't a common reference handy!? Or do you want both implemented Please answer this and settle the matter. The thrust of my arguments have been to establish which in the class of Abugida orderings has been applied as an alphabetic ordering. Such an ordering is then a candidate for the sequence to be used as an alphabetic ordered list. The dictionary inherently demonstrates which of the many tables is to be applied as an alphabetic ordering. Abugida (page 35) is a utility order, Ethiopic has many, but if you want to demonstrate it's use as an alphabetic order with some tangible evidence, you have your work cut out for you. I would be happier than you if such were found. Without demonstrating an order as having been used as an alphabetic sequence, or having been used otherwise in the special purpose of ordered lists, what supporting rationale can you come up with for implementing it? I can only see that it would make confused people happy. > that as there is a difference between "Ge'ez-Halehame" and > "Amharic-Halehame" ordering, there is also that difference in Take 3: locales, abass, locales ... language differences are handled thru locales. Read the 2001-10-08 posting on this issue. Each time you mention Amharic you are beating a dead horse. You bring up nothing new by telling us that Amharic is different from Ge'ez. > not. I might be wrong, but the page you sited here mention What page are you referring to? I've pointed to several URLs, none of which are public, if you find broken links and such please inform me before they go public. The Abegede Amharic order of KWK is uniquely his, I credited him where I used it. The order was not popularized though and another Amharic Abegede sequence has replaced it in time. > no KWK or DTK. Unfortunately, such misdeed is not new! If you are going to say it, support it. > By far this isn't an impressive list; don't you think so? It wasn't intended to be impressive, it is what I could offer in 5 minutes or less. You asked for something done in the last 50 years, and you got it, you didn't set a minimim.
1. Openness: I, still, strongly believe that the Ethiopic collation matter issue be shared with others who are directly or indirectly related to the subject. At least, it is fair to do so. 2. Ethiopic alphabetic List Order: a. In one of my previous messages, I have already included what my view is, but I would be very happy to refine it better. Below, you will find a structure which summarizes my view: + halehame-classic-ethiopic (Ge'ez) | halehame-------+ halehame-ethiopic (Amharic, Tigregna, Oromifa, Unicode) | + halehame-other-languages (?) + abugida-classic-ethiopic (Ge'ez) (KWK p. 34) [1] | abugida ------+ | + abugida-ethiopic (Amharic, Tigregna, ...) (KWK p. 40) [2] [3] I have a generated the two tables "abugida-classic-ethiopic" and "abugida-ethiopic" in HTML and PDF format to avoid any confusion and misunderstanding. http://www.senamirmir.com/ethiopic/tables/ace.html http://www.senamirmir.com/ethiopic/tables/ace.pdf http://www.senamirmir.com/ethiopic/tables/ae.html http://www.senamirmir.com/ethiopic/tables/ae.pdf b. The question now, is Mozilla going to support both Halehame and Abugida with their variant versions? Your suggestion is that this can be solved using "locale". You repeatedly mentioned "locale" and I am not quite clear how that is going to be implemented by Mozilla with out hard-coding the sequence set for each language. I read from CSS2 specification that a style can be defined based on a "lang" attribute, but it has little support to the problem at hand. I would appreciate if you could say more about "locale". c. It seems to me that alphabetic list order should be addressed by CSS instead of just by a User Agent only. If CSS would have a feature that would allow a "sequence set" for alphabetic list, then hard-coding each alphabetic list order for each language into the UA may not be an absolute requirement. In fact, the UA may provide a general algorithm and a default features to supported languages in the form of a configurable text (XML). I really would like to hear/learn what falks have to say about this. d. On your previous message, you wrote and I quote "Abugida (page 35) is a utility order, Ethiopic has many, but if you want to demonstrate it's use as an alphabetic order with some tangible evidence, you have your work cut out for you..." I am at a loss at this statement because you have this table as Abegede at your page and if I may add, it is this table that has been implemented by Jungshik. 3. This is just for your own information; that is, in DTW's book at page "Ye" where he has a publication information, you will find "Order/Arrangement is based on Abugida"[3] ________________________ Reference [1] Kidane Wold Kifle (KWK). Mitsehafe Sewasewu Wegiss Wemizgebe Kalat Haddis, 1955; pp. 34-35 [2] Kidane Wold Kifle (KWK). Mitsehafe Sewasewu Wegiss Wemizgebe Kalat Haddis, 1955; pp. 40. [3] Desta Tekle Wold (DTW). Addis Ye-amerigna Mizgebe Kalat Haddis, 1970; p. 10.
> 1. Openness: I, still, strongly believe that the Ethiopic > collation matter issue be shared with others who are > directly or indirectly related to the subject. At least, > it is fair to do so. 11 individuals, linguists, orthography experts and some software developers reviewed the information between mid-May thru the end of August of this year before the feature request was composed and submitted in late September. My role in this statge is as a lobbyist. A wider audience review would be required when ECoSA presents the matter. > I have a generated the two tables "abugida-classic-ethiopic" > and "abugida-ethiopic" in HTML and PDF format to avoid any > confusion and misunderstanding. These are in what I have been calling the "Abegede" sequence. The only problem that I can forsee with calling these orders "Abugida" (as KWK avoided doing so) is that a person using a list style with the name "abugida" might be surprised when the order they get is something different from true Abugida. To highlight the difference I now have: http://www.ethiopic.org/Collation/AbegedeVsAbugida.html > d. On your previous message, you wrote and I quote > > "Abugida (page 35) is a utility order, Ethiopic has many, > but if you want to demonstrate it's use as an alphabetic > order with some tangible evidence, you have your work cut > out for you..." this remains true. > I am at a loss at this statement because you have this table > as Abegede at your page and if I may add, it is this table > that has been implemented by Jungshik. this is also true. The OrderedList.html tables did show Abugida and not Abegede. Sorry for the confusion, a script error apparently (my responsibility), the tables are now corrected.
So does the above patch represent the consensus on the correct thing to do?
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.7
> So does the above patch represent the consensus on the correct thing to do? the patch, with the order fix sent to jungshik, and the label change from "abegede" to "abugida" should satisfy the consensus view point.
Daniel, I applied what you sent to me to my patch and I'm gonna post a new patch once it gets compiled and tested. (perhaps after bugzilla is back)
Daniel, Reading your email containing fix, I got confused. Which name should I use for the sequence you sent off-line, Abegede or Abugida according to the consensus view? The sequence sent off-line appears to be what you call 'Abegede' at http://www.ethiopic.org/Collation/AbegedeVsAbugida.html and you wrote to that effect in your email. However, you also wrote here: > the patch, with the order fix sent to jungshik, and the label change from > "abegede" to "abugida" should satisfy the consensus view point. Could you clarify this and let me know what consensus viewpoint is? (which sequence and which name)
Jungshik, just briefly: What I've called "Abegede" should be in mozilla: -moz-ethiopic-abugida This is in the corrected table I mailed you and is the basis of the tables Abass posted as well. What I've called "Abugida" should be in mozilla: -moz-ethiopic-abugida-ahaze This is in the originial table that you implemented (as per my earlier mistake). I can elaborate on why "ahaze" is a logical name but I'll skip that for now unless there are requests.
Daniel, Sorry for the late reply. Is it all right to support only Halehame and Abugida(which was called 'Abegede' in my old patch) or do you want me to add Abugida-ahaze as well now? The latter is kinda locale-specific, isn't it? If so, I'm inclined to support Halehame and Abugida (along with the Ethiographic numeric list-style) for now and add locale-specific ones later when we figure out what to do with locale-dependence of list-styles.
> or do you want me to add Abugida-ahaze as well now? Yes, to add abugida-ahaze as a list style as well. I think if you have the first style with the label "abugida" it will confuse some number of people who saw the label and expected the second style (abugida-ahaze). So if one is supported under this name convention then both styles should be there. So I recommend having either both abugida styles or none at all. Having only one with this label will invoke confusion eventually. > The latter is kinda locale-specific, isn't it? Any of the letter element based list styles would be influenced by a locale setting. But this is not unique to Ethiopic script and languages. > for now and add locale-specific ones later when we figure out what to do with > locale-dependence of list-styles. I thought this would be an old problem for mozilla. Doesn't an alphabetic list style change when a user locale is set for French, German, Swedish, etc which have extra elements vs English? The same priniciple applies to Ethiopic, the root character set is that of Ge'ez, other languages mostly add to it. Ge'ez is what you would use as a default if locales are not to influence the list style or if a locale setting is not applicable to Ethiopic. So using what you have already, which is for the Ge'ez set, is fine, it would be universally acceptable. The minimalistic support level for Ethiopic list styles, if mozilla and netscape staff would like to start off more cautiously and simply, would be to have the numeric and the Halehame (Ge'ez set) list styles only.
Kats, Frank and David, What would you say? I'm inclined to go with Ethiopic-numeric and Halehame for now.
Idoubt if we have locale-dependent treatment of something "lower-alpha", i.e. changing alphabetic characters based on locale differences. So, yes, I agree with Jung-shik's suggestion to go with what we can support at this point.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
We are no Ethiopian expert. We should let it in if (1) no crashing problem, (2) the author is confident about his knowledge. What will happen if the algorithm is WRONG? Well... if that happen, we got bug report from other and we fix it.
Comment on attachment 54039 [details] [diff] [review] a new patch that really works I don't see + case NS_STYLE_LIST_STYLE_MOZ_ETHIOPIC_NUMERIC: in the last part, is that right ? r=ftang
I thought the conclusion from the discussions since the most recent patch was that there needed to be some changes to that patch.
A new patch based on the consensus(it also addresses Frank's comment about the source format in October). This implements only Ethiopic-Numeric and Ethiopic-Halehame. Abugida and Abegede are left out for now.
Frank/David, can you review it just in case? It's basically the same as previous one except that Ethiopic-Abegede was removed. Then, I'll ask for sr. > I don't see + case NS_STYLE_LIST_STYLE_MOZ_ETHIOPIC_NUMERIC > in the last part. Ethiopic-numeric is not necessary in the last part. It's only for those list styles with fixed-length hardcoded elements.
>Yes, to add abugida-ahaze as a list style as well. I think if you have the >first style with the label "abugida" it will confuse some number of people who >saw the label and expected the second style (abugida-ahaze). So if one is >supported under this name convention then both styles should be there. >So I recommend having either both abugida styles or none at all. Having only >one with this label will invoke confusion eventually. So the newest patch have "none". Why don't we go for the "none plane" now and you can give a new patch for "both" later. >I thought this would be an old problem for mozilla. Doesn't an alphabetic list >style change when a user locale is set for French, German, Swedish, etc which >have extra elements vs English? not true, in mozilla, we got the SAME list regardless French, German, or Swedish. The list style itself is already a switch of cultural, there are no need to add more complexity to it. If people really need a german list, we should add a german-lower-alpha instead of depend on a different variable, e.g. locale.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Thank you for the note. > Did you want to ask for super-review? See Don't I need review first? I've been waiting for it. Why don't you give 'r' if you think it's all right? Then I'll go ahead.
Comment on attachment 62532 [details] [diff] [review] a new patch based on the consensus >+static void EthiopicToText(PRInt32 ordinal, nsString& result) >+{ >+ nsString asciiNumberString; // decimal string representation of ordinal This should be an nsAutoString, no? >+ DecimalToText(ordinal,asciiNumberString); >+ PRInt32 n=asciiNumberString.Length()-1; Nit: compared to below and prevailing style in the file, these two seem short spaces (space after comma, around binary operators). >+ >+ // Iterate from the lowest digit to higher digits >+ for (PRInt32 place=0; place <=n; place++) { Nit: a space after the <= would be nice. >+ PRUnichar asciiTen = (PRUnichar) 0x30; // '0' No need for the comment if you just use (PRUnichar) '0' or even '0' -- there is no need for a cast, either. >+ PRUnichar asciiOne = asciiNumberString.CharAt(n-place); >+ >+ place++; >+ >+ if (place <= n) >+ asciiTen=asciiNumberString.CharAt(n-place); Spaces around the = operator would be nice. >+ >+ // '00' is not represented and has to be skipped. >+ if ((PRInt32) asciiOne == 0x30 && (PRInt32) asciiTen == 0x30 && place < n) >+ continue; Again, use '0' rather than 0x30 for clarity. Again I see no need for the (PRInt32) casts. >+ >+ nsString ethioNumber; nsAutoString, not nsString. >+ >+ // calculate digits at 10^(2*place) and 10^(2*place+1) >+ if ((PRInt32) asciiTen > 0x30 || (PRInt32) asciiOne > 0x31 || place == 1) >+ { >+ if ((PRInt32) asciiTen > 0x30) Same comments as above about needless casts and '0' (or '1' for 0x31 -- is that 0x31 correct, or should it be 0x30?), plus there is an extra space after each > operator here. >+ { >+ //map onto Ethiopic "tens": 0x1372=Ethiopic number ten A space between // and map here would match your comment style elsewhere. >+ ethioNumber += (PRUnichar) ((PRInt32) asciiTen + 0x1372 - 0x31); >+ } >+ if ((PRInt32) asciiOne > 0x30) >+ { >+ //map onto Ethiopic "ones": 0x1369=Ethiopic digit one >+ ethioNumber += (PRUnichar) ((PRInt32) asciiOne + 0x1369 - 0x31); >+ } >+ } >+ >+ // Now add 'cental-place' specifiers in terms of power of hundred >+ >+ if (place > 1) >+ { >+ if ((place/2)%2) // if odd power of hundred An optimizing compiler should know that place is never negative, and avoid an extra test -- and strength-reduce the div and mod to &, but you could just write if (place & 2) to test the same thing. >+ ethioNumber += (PRUnichar) 0x137B; // append Ethiopic number hundred >+ >+ // append Ethiopic number ten thousand every four decimal digits >+ for (PRInt32 j=0; j< (place/4); j++) >+ ethioNumber += (PRUnichar) 0x137C; // 0x137C = Ethiopic number ten thousand >+ } >+ >+ result.Insert(ethioNumber,0); >+ } >+} Fix these nits and sr=brendan@mozilla.org. /be
Attachment #62532 - Flags: superreview+
I think I can just go ahead, but just in case, I'm attaching a new patch with nits fixed. brendan, can you take another quick look? Thank you,
checked in (attachment 68832 [details] [diff] [review]). David, can you change the status?
Since you have cvs access now, you can feel free to assign bugs to yourself when you have fixes. :-)
Assignee: dbaron → jshin
Status: ASSIGNED → NEW
... and marking FIXED, since you checked it in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
David, thank you. Daniel and Kats, can you verify ?
Jungshik, Thanks for the great work! I did test with the nightly build for linux that was available monday morning. It was perfect! I'll report to you if I can break it under more complex scenarios.
can somebody please verify this bug ?
Madhur, This bug can be closed, mozilla works as expected here. Bug 173408 is an important follow up that needs attention.
Status: RESOLVED → CLOSED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: