Re: Personal names survey
Here are my observed rules of 'pronouncing' kasre ezaafe in pronunciation of first name. Rule 1: The following rules only apply when first name is followed by last name Rule 2: Do not add ksare ezafe at the end of names foreign origin, even if they come from a Persian speaking country, e.g. Ahmad Shah Masoud. Rule 3: Do not add kasre ezaafe at the end of first names ending with vowels, e.g., Ali, Minoo, Saba, Reza, Kaveh. However, adding a YEH + KASRE is sometimes done only for dramatic effects. For example, pronounce Ali Heydari as written, but it is acceptable (but not customary) to pronounce as Ali Ye Heydari. Rule 4: Do pronounce a weak, almost unnoticeable kasre ezafe at the end of first names ending with a consonant. On Sun, 13 Jun 2004 15:50:13 +0430, Roozbeh Pournader [EMAIL PROTECTED] wrote: On Sun, 2004-06-13 at 04:52, C Bobroff wrote: You have! You just didn't notice. You also put them (i.e. pronounce the ezaafe) in personal names when speaking which you also don't notice. Like in feredrish-e niche, or reymond-e kaarver? ;) roozbeh ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: Mirroring in Unicode
Hi Behdad, On Fri, 11 Jun 2004 05:34:42 -0400, Behdad Esfahbod [EMAIL PROTECTED] wrote: Yes this has been the rule for a few years, but everyone is so scared about auto-inserting marks and later dealing with them, without cluttering the text much. One such implementation is KDE's parantheses fixing idea based on keyboard layout which is considered quite a failure (read on Arabeyes wiki page for Qt bugs). I finally figured out that if I insert either an RLE or an LRE character right before each open parenthesis and a PDF character right after each close parenthesis then all parenthesis are matched and also their nesting level is preserved as well. Is this something guranteed, or is that I could not find a bad example where this breaks? Also, is this the KDE's parenthesis fixing idea you are refering to above? -- ODC ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: khaat e Farsi
On Sat, 12 Jun 2004 12:14:40 +0430, Hooman Mehr [EMAIL PROTECTED] wrote: More clarifications, questions and opinions: 1) Clarification: Are we talking English or Persian? a) The English name of the concept in the locale document is Arabic Script and it is not up to us to discuss or change it. It is already decided and used a long time ago. (So Connie don't worry, it won't create the kind of confusion you feared) b) We can only put a Persian phrase we standardize for referring to that concept in our own locale spec. c) The phrase does not need to be a literal translation of Arabic Script 2) Observation/Retreat: Nationalistic considerations. I confess that I underestimated nationalist feelings that the word Arabic carries among Iranians. So, I change my stance and think that we have to avoid anything that can hurt people's feelings. Assuming the heated reaction we saw here is an indication of the possible general public reaction, I vote against using arabi to name the family of scripts that our script belongs to. 3) Question: Khatt-e Farsi overload issue Issue: If we use Khatt-e Farsi for the family of scripts and again Khatt-e Farsi for Persian variant of it, the two will not be distinguished. [1] Question: Are you comfortable with this overload of concepts? Should we ignore this issue? I personally do not mind using the same term for these two concepts. 4) Call for fresh ideas: a) Is there any idea besides Khatt-e Farsi and Khatt-e Naskh [2]? b) Does anybody know of a phrase that better matches the concept at hand? c) Can't we come up with a word other than Khatt to call this concept of a script family? I noticed that an old Persian word for Script is 'dabeere' spelled dal be ye r ye heh We can use that as well to call Arabic script, 'dabeere ye faarsee',. I am personally inclined towards a new and unfamiliar (but sounding familiar) term without using the word Khatt. - Hooman Mehr Endnotes: [1] For the information of people quoting constitution, what is called Khatt-e Farsi is the second concept (Persian variant of the Arabic Script) not the first one. As far as I am aware, there is no official name for the general family of scripts that encompasses ours. [2] I still oppose Khatt-e Naskh for the following reasons: 1) As a script name, it is used in the context of evolution of writing systems not present day distinction among script families. 2) It is confused with calligraphic style with the same name. The name is well known to ordinary people as calligraphic style but never heard by general public as script name. So, the chance of confusion is initially almost 100%. 3) The key: I am personally inclined towards a new and unfamiliar term. Because the concept is not truly familiar for normal people. Khatt-e Naskh is too familiar in a different context, I don't like using it for an unfamiliar concept. You may not find my reasons compelling but I am not trying to convince anybody, I am just saying why I am not still convinced and probably will never be because the third and the key part is mostly a matter of preference and not logic. ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Mirroring in Unicode
I noticed that certain mirrored characters appear semanticly wrong on my Windows XP machine. I have no idea if it is a problem of Unicode BIDI specs or is due to Windows XP imeplementation. I describe the problem here, hoping people who know Unicode better pinpoint the source of it. I if type in: (farsi), that is the sequence T A R SP ( f a r s i ) (capital stands for RTL text), the result is RAT (farsi) However, if I type in () that is the sequence T A R SP ( F A R S I ) the result is ISRAF) RAT) Obvisouly the parenthesis are wrong in the second example. Now, if this is a unicode spec problem, I think they need to fix this. How the above text appears on other platforms? ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: Mirroring in Unicode
Hi Behdad, I just finished finding the relevant part (Rule L4 of UAX #9) of Unicode specs refering to mirroring. I believe the problem I am complaining about is still a problem and is due to bad Unicode specifications. I do not know how Unicode got mirroring into their standard, and their rationals behind this. However, in my opinion, the correct semantics is that if the input text has matched open and end parenthesis then the visual output should also have matched left and right parenthesis regardless of the paragrpah mode. Obviously the Unicode specs break this semantics when the text is RTLTEXT(RTLTEXT) and the paragraph is in LTR mode (or vice versa). While we are talking about the semantics behind BIDI algorithm, I was wondering if BIDI algorithm assigns the same direction to characters regardless of where a line is broken. Which apparenly does not! For example, type in This a very very long line +-* *-+ this is the question! in a multiline input area. Notice the visual order of *-+ is the same in both occurneces. Now, insert spaces in the beginning until you get both of the *-+ on the seocnd line. Now observe the difference in ordering of the *-+. I again believe this is a design defect of BIDI specifications. Whereas, it only looks at one line at a time, and does not allow (unless I am mistaken) for state information to be propagated across lines when breaking lines. A better design would have allowed (and required) to pass necessary state information from one line to another such that the visual ordering would have stayed the same regardless of where the lines are broken. Of course, a typical reply could be that I need to insert some control characters to achieve the desired ordering. Then, my rebuttal is that if that is the case, why not make the control characters for such cases mandatory? Anyway, I have no hope of achieving any positive contribution at Unicode consortium (or other big standard groups like that). So, I am going to turn this into something more fruitful. That is, I like to put the burden of correcting these flaws at the UI. Or: The UI should add control characters at proper places to the user text such that the text renders semantically correct regardless of BIDI inconsistencies I think satisfying the above requirement is not trivial, but challenging enough to keep a few good minds busy thinking about it. On Thu, 10 Jun 2004 21:47:03 -0400, Behdad Esfahbod [EMAIL PROTECTED] wrote: Hi Ordak, This is not a problem in the Unicode Bidi Algorithm, not even in Microsoft's implementation of the algorithm. And mirroring seems to be working quite well. The problem is in the higher level protocols of your system, which simply does not recognize right-to-left paragraphs. So your paragraph direction is left-to-right, and that's why you see it like that. Microsoft systems have no way of auto-detecting paragraph directions. In notepad you can set the whole document direction to rtl or ltr. In MS Word you can set direction for individual paragraphs. GNOME has recently applied a marvelous patch to autodetect paragraph directions in the most sophisticated way, so we're just having fun with our text editors ;-). behdad On Thu, 10 Jun 2004, Ordak D. Coward wrote: I noticed that certain mirrored characters appear semanticly wrong on my Windows XP machine. I have no idea if it is a problem of Unicode BIDI specs or is due to Windows XP imeplementation. I describe the problem here, hoping people who know Unicode better pinpoint the source of it. I if type in: (farsi), that is the sequence T A R SP ( f a r s i ) (capital stands for RTL text), the result is RAT (farsi) However, if I type in () that is the sequence T A R SP ( F A R S I ) the result is ISRAF) RAT) Obvisouly the parenthesis are wrong in the second example. Now, if this is a unicode spec problem, I think they need to fix this. How the above text appears on other platforms? ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing --behdad behdad.org ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: UI problems in editing BiDi texts.
Please ignore this while I can successfully prepare a long e-mail with gmail :( On Tue, 8 Jun 2004 17:08:53 -0400, Ordak D. Coward [EMAIL PROTECTED] wrote: Following up the old thread, here is my attempt to understand the problem. We may then agree on a desired behavior, and then on an implemenation. The problems appear when typing a text in a BiDi enabled editor. it seems to three categories of concren. 1) When typing a bilingual text, the cursor jumps unexpectedly. An example, is when I type HERE IS SOME RTL TEXT, (where UPPERCASE stands for RTL characters), in notepad or any input line, the cursor (denoted by |) and text appear as follows: | |EH ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Misinformation!
I recently came across this article http://www.khabgard.com/?id=844986758 which is endorsed by some other weblog authors. The author encourages using adifferent Yeh characters for middle and end placements. The author in fact uses U+064A(ARABIC LETTER YEH) for middle-of-word and beginning-of-word Yeh's and uses U+06CC (ARABIC LETTER FARSI YEH) for end-of-word Yeh's. I believe he is giving bad advice to people. His jsutification is that people with older MS-Windows systems will see texts correctly by his suggestion. This is bad principle to bend standards to support non-comppliant platforms. I am going to send an e-mail to him about the issue, but I want to confirm my understanding of the issue before contacting the author. Furthemore, while he correctly asks people to use U+06F4, U+06F5, and U+06F6 in place of U+0664, U+0665, and U+0666, he stops there and does not extend this advice to all digits. Is there a trustworhty easy-to-read document somewhere on the Internet that mentions all this issues that I can refer people to it? ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: LeapYears of Iranian Calendar
I downloaded and tested a few dates with the Win32 executable of Jalali (the one at sourceforge). The bad news is that, the conversion is not correct. The conversion is wrong for 20 March 2005, and similarly a few other dates that should convert to 30 Esfand Year YYLP, instead all such dates convert either to 1 Farvardin YYLP or 1 Esfand YYLP, depending on how the date os set to 20 March 2005. The good news is that, the jalali.c source does convert such dates correctly. On Mon, 24 May 2004 02:19:09 -0400, Behdad Esfahbod [EMAIL PROTECTED] wrote: So, to conclude, I think we better don't touch the 33 implementations we have until we've got a real calendar. Just talking about FarsiWeb of course. Other people are free about what they choose. behdad On Mon, 24 May 2004, Ordak D. Coward wrote: I did some more research on the accuracy of different leap year algorithms. My conclusion is that unless there is an implementation of an astronomical algorithm, we SHALL use the 33 year period, as it gives the best estimates for near future and near past. That is, use the following: bool isLeapYear = ((y*8+29)%33) 8; I used the following table of vernal equinox times for years 1788-2011: http://www.newscotland1398.net/equinox/vern1788.html I computed the length of year for each year. and unfortunately, I could not find any simple curve to fit the length of years. Assuming that the real vernal equinox does not differ from the table above by more than +/- 10 minutes, and that the noon will be at 12:04:20, I am convinced that this formula is correct at a minimum from 1178 to 1468. At the same time, the Birashk's method and hence Omid K. Rad's implementation are only correct from 1244 to 1402. Another way to interpret this email is that Birashk's method fails to correctly predict the year 1403, and hence if we use that mehtod, all dates in year 1404 will be off by one day. On the other hand, using the 33 year period mentioned above works fine until year 1468. So, for all applications that need to convert near-term dates, my recommendation is to use a 33-year implemntation, like the one found at http://www.farsiweb.info or the one at http://www.payvand.com/calendar/. -- ODC ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing --behdad behdad.org ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: LeapYears of Iranian Calendar
On Thu, 20 May 2004 22:30:33 -0400, Behdad Esfahbod [EMAIL PROTECTED] wrote: On Thu, 20 May 2004, Ordak D. Coward wrote: Ordak's 2820 year method: bool isLeap2820ODC = ((683*year+542) % 2820) 683; in comparison to: Birashk's 2820 year method: bool isLeap2820Birashk = ((year % 2820) == 474) || (((31 * ((year+2345) % 2820)) % 128) 96); I second that. Here is my version, in a desktop calculator friendly (and macrowize side-effect-less) way: #define is_persian_leap(y) y)-474)%2820+2820)%2820*31%12831) Nice. The discrepancies will be in: years that Ordak considers leap but not Birashk 603, 731, 859, 1787, 1915, 2043, 2171, 2299, 2427, 2460, 2555, 2588, 2683, 2716, 2811, 2844, 2939, 2972, 3067, 3100, 3133, 3195, 3228, 3261, 3295 and years that Birashk considers leap but not Ordak 602, 730, 858, 1788, 1916, 2044, 2172, 2300, 2428, 2461, 2556, 2589, 2684, 2717, 2812, 2845, 2940, 2973, 3068, 3101, 3134, 3196, 3229, 3262, 3294 Caveat: According to: http://scienceworld.wolfram.com/astronomy/TropicalYear.html The length of year is decreasing each year. According to graphs in http://www.angelfire.com/dc2/calendrics/ The real length of vernal equinox year (Iranian year) is increasing each year (from 351 BC to 3175 A.D.) According to Iranian tradition, vernal equinox should happen before noon (I think it means astronomical noon). So, there is not much we can do with simple algorithms other than trying to approximate the real world, and understanding the fact that ALL calendar algorithms are only APPROXIMATIONS. -- ODC Well, so what do you suggest? Working on an approximate astronomical algorithm or go with Birashk's? I guess the best thing to do: - is get an archive of the last 50 years of official times of vernal equinox, or saal tahveel, and compute the length of year for each year. Fit them with linear or quadratic curves. Look at Birashk's method and see how much Birashk's length of year differs from official length of year. Also, look at the real variation of length of years, compute the calendar for the next 1000 years using both Birashk and the curves. Decide if using the curves will result in less error. Here is an attempt to guesstimate when the official calendar starts to diverge from Birashk's. A rough look at the last few years variation of length of years show a variation of up to 5 minutes. So, each 144 years or so (24hours / 10 minutes) , we have a year whose VE is +/- 5 minutes of noon. Hence, as long as we use a constant for the length of year, it is very likely to see discrepancies once every 144 years. However, this WILL happen as early as 1404. That is, if my calculations are correct Birashk's method gives year 1404 as a leap year, but I get 1403 as a leap year. (I am using some acceptable length of years). That is, the VE of year 1404 should happen around 12:30pm which if it considered afternoon, it shall be Esfand 30th of 1403. THIS IS IMPORTANT AND SHOULD BE DEALT WITH. No amount of observational errors can compensate this. Considering the computational power available today, it is a shame if we stick to a method using constant length of year which were only appropriate for pre-computer era. -- ODC ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
LeapYears of Iranian Calendar
I was looking at Omid K. Rad's implementation of calendar, and have a few comments on calculating leap years. 1. The implemented algorithm uses a 128 year period, although the comments say it uses a 2820 year period. While I need to ask for this discrepancy be resolved, it is important to understand that the 128 year period and the 2820 year period only differ once every 2820 years. In other words, the current implementation does not differ from the 2820 year method until year 3294 A.P (or H.S.). 2. However, it seems to me that the 2820 Birashk method -- the one with 21 128 year period and one 132 year period -- will start showing discrepancies with the observed norouz as early as 1788 A.P. The reason, is that the Birashk method tries to be in sync with the 128 year method as much as possible, and adjust the extra leap year at the end of 2820 years. However, the earth does not care about this assumption, and will rotate around the sun constantly (see caveat below), unless Birashk has considered the variation of length of years The correct 2820 year formula will then be: (based on the assumption that there are 683 evenly spread leap years in 2820 years, and also aligning the leap years with the largest extent of years around today) Here, variable year refers to year in A.P or H.S. Ordak's 2820 year method: bool isLeap2820ODC = ((683*year+542) % 2820) 683; in comparison to: Birashk's 2820 year method: bool isLeap2820Birashk = ((year % 2820) == 474) || (((31 * ((year+2345) % 2820)) % 128) 96); The discrepancies will be in: years that Ordak considers leap but not Birashk 603, 731, 859, 1787, 1915, 2043, 2171, 2299, 2427, 2460, 2555, 2588, 2683, 2716, 2811, 2844, 2939, 2972, 3067, 3100, 3133, 3195, 3228, 3261, 3295 and years that Birashk considers leap but not Ordak 602, 730, 858, 1788, 1916, 2044, 2172, 2300, 2428, 2461, 2556, 2589, 2684, 2717, 2812, 2845, 2940, 2973, 3068, 3101, 3134, 3196, 3229, 3262, 3294 Caveat: According to: http://scienceworld.wolfram.com/astronomy/TropicalYear.html The length of year is decreasing each year. According to graphs in http://www.angelfire.com/dc2/calendrics/ The real length of vernal equinox year (Iranian year) is increasing each year (from 351 BC to 3175 A.D.) According to Iranian tradition, vernal equinox should happen before noon (I think it means astronomical noon). So, there is not much we can do with simple algorithms other than trying to approximate the real world, and understanding the fact that ALL calendar algorithms are only APPROXIMATIONS. -- ODC ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Iranian Calendar
After reading the recent discussion on Iranian Calendar and its support in .NET, I have a few suggestions: - As the lunar calendar in Iran is observation based, there is no way to have an exact conversion for a date in future to/from lunar calendar. However, it is possible to do so for past dates. What I suggest is that the implementation SHALL convert dates precisely for past dates, and do a best guess conversion for future dates. Hence, the conversion algorithm (or a related resource) needs to be updated at most 12 times a year, and in case of Iran, only at the beginning of Ramadhan and Shawwal. This update could as well be propagated through a network protocol like NTP (Network Time Protocol). Also, the conversion shall try to conform to the official published Iranian calendar for future dates in the same year. For future years, it should calculate the lunar calendar using astronomical methods. - Mordad vs. Amordad. I have seen both in calendars, but I guess I do not count, as I have been out of Iran for a long time now! Anyway, I have only seen Amordad in day planners marketed at the higher end. So, in my opinion, Mordad or Amordad are both fine. Although I prefer to see Mordad myself. But, I think this should be a user option. And does not need to be implemented at the convesion level Omid is working on. - b.z vs. asr. I do not know the flexibility of the API, but it would be nice if we can have three designators, sobh, asr and shab. sobh is for 6:00 am to 11:59pm. asr for 12:00 am to 5:59pm, and shab for 6:00pm to 5:59am. The time ranges are not exact, but they are close to what you hear if you want to set appointments in Iran. - Jalali vs Iranian. I strongly prefer Jalali, as it refers to a spcific method of keeping dates regardless of the country it is used in. For example, if were still under Qajar rule or Pahlavi rule, then we would have either used Hijri-Qamari calendar or Shahanshai, still both would have been considered Iranian calendar. So, in a country which has recently changed its official calendar a few times, we better stick to a name that will be in place regardless of the government. I am under the impression that the current calendar is use is techincally Birashk's calendar. Birashk perfected the old Jalali Calendar (which had 33/128 year periods vs 33/128/2820 year periods of Birashk). - Birashk's book. He had published a book on his work, if memory serves me, it was called 'taarikh-tatbighi-ye Iran'. He had a few examples of different date conversions, using a rather large table for lookups. That table could be used as a test vector for the date conversion utility. I once did my own derivations to derive his table, and except one entry, my code and his table conformed. I never figured the source of the discrepancy. -- ODC PS. I hope no one gets offended by my chouce of pseudonym. ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: Iranian Calendar
On Tue, 18 May 2004 02:58:05 -0400, Behdad Esfahbod [EMAIL PROTECTED] wrote: On Tue, 18 May 2004, Ordak D. Coward wrote: - Jalali vs Iranian. I strongly prefer Jalali, as it refers to a spcific method of keeping dates regardless of the country it is used in. For example, if were still under Qajar rule or Pahlavi rule, then we would have either used Hijri-Qamari calendar or Shahanshai, still both would have been considered Iranian calendar. So, in a country which has recently changed its official calendar a few times, we better stick to a name that will be in place regardless of the government. I am under the impression that the current calendar is use is techincally Birashk's calendar. Birashk perfected the old Jalali Calendar (which had 33/128 year periods vs 33/128/2820 year periods of Birashk). I'm still against Jalali, because as Roozbeh mentioned, the Jalali calendar has been different in number of months. To be exact, we should call it Birashk, but since it's highly unprobable that the Iranian calendar changes again, I say lets stick with Iranian Calendar. I could not find Roozbeh's post your are refering to. However, the main difference is the the name of the months and the number of days in each month, at least from what I understood from Iranica. I went back and read most of the Iranica's entry on calendars. It seems to me that the correct name of the current calendar in Iran is Hijri Shamsi, and NOT Jalali calendar, so I take back the suggestion of Jalali. As the first day of year in H.S. calendar is Norooz-e-Jalali, then a common misconception is that H.S and Jalali are the same. Norooz-e-Jalali refers to the method of detrmining the first day of the year -- the day sun enters Aries. Iranica also mentions a 128 year period for calculating leap years, which I think is the same method Omid is using is his implementation. I guess the 33 year period is attributed to Khayyam. And, 2820 year period to Birashk. Now, I have no idea which calendar the Iranian government uses. I also found the link: http://www.angelfire.com/dc2/calendrics/ which I find interesting and amusing to read. Essentially the author argues that the 33 year period of leap years is more precise than the 2820 year period. About Shahanshahi era, a good converter can assume years 2500-2600 are in this era (Hint Hamed). It is essential that te converter should let the user know about this assumption. -- ODC ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
