Re: Behaviour of U+002F in IE and Mozilla
The behavior was changed between Unicode 4.0 and 4.0.1! With the latest Unicode version, using Persian digits, in a Persian paragraph, something like 1361/07/05 will render 1361/07/05, not 05/07/1361, which is a good thing. (Using Arabic digits instead of Persian digits most probably result in the other way). Do you know which systems actually implement 4.0.1 bidi algorithm? Does installing your latest FriBidi library completely address this issue on Linux? Hooman Mehr ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: [Persian Locale d6 Feedback] Short Format Dates
Hi Behdad, On Jun 26, 2004, at 1:50 AM, Behdad Esfahbod wrote: I'm confused now. What do you expect in PropList.txt about U+060D? If you read UCD.html, it says that files like PropList.txt just list those code points that hold a true value for the binary property. Why they don't list the all?? Why should the do? There are more than a million of them, while poins of interest are usually less than a thousand ones... behdad You are right, that was my mistake. I had some wrong perceptions about U+060D that made me believe it would belong there. I am starting to feel I need to import all those data files into a database for quick reference. I am getting tired of having to find information scattered across so many different places (book, charts and various data files) I still feel there should be a better way for organizing all the information in Unicode. - Hooman ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
[Persian Locale d6 Feedback] Short Format Dates
Dear Roozbeh, In page 2 (physical page 3) of the Locale draft, the short format locale is specified in a table with some examples and explanation. The missing information is this: We know that the correct way to read (pronounce) a short format date that looks like 1358/1/12 is 12-e Farvardin-e 1358 just like the long format (Don't get to kasre-ye ezafe debate please, this is not what I mean). Since Unicode assumes that text is entered in the same way that it is intended to be read (pronounced or processed, which is called the logical order), one expects to be able to do the following data entry: 12 followed by / followed by 1 followed by 1358. I suspect that you didn't type it like that, because the normal software would result a display of 12/1/1358. The reason is that / (slash, U+002F) is a neutral character and when surrounded by digits it gets left-to-right directionality according to Unicode bi-di algorithm. In short, there is no mention of how you get the display results that you are showing in the tables. There are many ways that you can enter data and embed or assume different directionality and get the same visual results. I think you should be specific about directionality assumptions. The logical short format in Persian is day, month, year, but with normal delimiters and digits this is not how you get the visually correct result of year/month/day. The best solution in my opinion is to provide exact format strings (as arrays of Unicode characters with specific placeholders for date elements). This will avoid any possible ambiguity in the specification. I sincerely hope that you won't tell me that you expect the users to type 1383 then / then 1 then / then 12 to enter a date in short format, because it would be unnatural and none obvious (although currently it may be the only way to get a correct result with the available software applications). The debate here is whether we should turn workarounds that are logically questionable into standards that are assumed to have sound logical foundation. As I have seen, you have defended going back to using the correct yeh and correcting the faulty software/fonts, so I hope you choose the right thing to do this time as well. Alright I know, you may say: It is impossible any other way! What is the solution? Answer: Nothing is impossible, but the answer is gonna cost you! - Hooman Mehr ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: Mirroring in Unicode
On Jun 12, 2004, at 4:14 PM, Behnam wrote: I had discussion with an Apple developer on this subject. She insisted that this is the way Unicode wants the mirroring characters to behave and that Apple has no intention to change its implementation of them. There has been a misunderstanding in your conversation and in a sense both of you are right. As I develop this topic further you'll better understand it. I hope she would read my posts (if she has any influence on Apple) so that something would get fixed on Apple's side as well. On the other hand, what she needs to realize (along with most of the other developers) is: Unicode does not have to dictate the user interface of text input and editing. The user interface of text editing can be vastly improved if we properly design a GUI-optimized model to hide the true underlying Unicode bidi semantics in favor of easier and more user friendly semantics while maintaining 100% Unicode compatibility. On the other hand, I suspect you have font related issues. read below... This whole thing means that on Mac platform we will see the wrong parenthesis on Persian web-pages forever! Part of the issue you are experiencing could be related to fonts. Persian/Arabic Apple fonts need a suitable character property table to identify mirrored glyphs and behave correctly. Please compare the behavior of Geeza Pro standard system font with the fonts you are using. If they are different it is becuase of the missing or improperly formed 'prop' table in the font. (http://developer.apple.com/fonts/TTRefMan/RM06/Chap6prop.html) If this is the case let me know to see how I can help fix them. I guess that along the effort in finding a proper solution for handling of mirroring characters, there has to be an effort to remove this useless mirroring effect in Unicode altogether. Don't even think about that. In the text stream level using logical opening and closing parenthesis instead of visual left and right parenthesis is actually very helpful in keeping the logical text processing model simple and elegant. Also, too many things already depend on it. We need to address this issue in text input/editing services of the operating system without touching Unicode. As I mentioned Unicode is not at fault here. The current assumption that the Unicode model necessarily applies to the user interface is the problem. - Hooman Mehr ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: Mirroring in Unicode
Hi, I checked it and can confirm that Apple's ISIRI 2901 keyboard has a bug in this regard. The Persian opening parenthesis in ISIRI 2901 is located on shit-0 and closing parenthesis on shift-9, but Apple's implementation have them reversed. This is a minor issue. The keyboard file is an XML file that can be easily edited with sys. admin. privileges. I think someone already posted information on a fixed and enhanced Persian Mac OS X keyboard on the list. - Hooman Mehr On Jun 12, 2004, at 6:12 PM, Behnam wrote: On 12-Jun-04, at 8:50 AM, Hooman Mehr wrote: On the other hand, I suspect you have font related issues. read below... This whole thing means that on Mac platform we will see the wrong parenthesis on Persian web-pages forever! Part of the issue you are experiencing could be related to fonts. Persian/Arabic Apple fonts need a suitable character property table to identify mirrored glyphs and behave correctly. Please compare the behavior of Geeza Pro standard system font with the fonts you are using. If they are different it is because of the missing or improperly formed 'prop' table in the font. (http://developer.apple.com/fonts/TTRefMan/RM06/Chap6prop.html) If this is the case let me know to see how I can help fix them. I do all my tests with Geeza Pro and ISIRI keyboard does produce the opposite of intended parenthesis with Geeza Pro. Apple Persian keyboard produces the intended one because as I said it is mapped in the opposite way. My other fonts behave similarly which, I suppose, is good news! Behnam P/S I'm very interested to present this discussion to Apple developer and I'm working on it. ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: Mirroring in Mac OS X (was Mirroring in Unicode)
Dear Behnam, No, this is another story. The sad news is that there are multiple implementations of Unicode in Mac OS X. WebKit (The engine of Safari) has its own Unicode/Bidi engine. Cocoa has its own Unicode with no native Bidi with some ugly Carbon ATSUI patches bolted on and some ICU thrown in to get limited Bidi. Carbon uses an incomplete and degraded implementation of ATSUI which is a downgraded and crippled version of QuickDraw GX layout engine of system 7 days. That is not all. I really hope Apple will start to clean up this extremely ugly mess, otherwise they will be forced out of bidi markets for good. It is amazing how much worse their bidi text engine is compared to 12 years ago. The problem is that each of these have their own bugs. Sometimes the bugs are a result of the same thing being applied twice because of API layering. This is the case with Safari. In some combinations of style sheet and page tags it tends to mirror a glyph twice which will result-in no mirroring which is wrong. Actually the workaround in such case is to use a buggy font which does not have a 'prop' table (like a PC font) and then it will work because it would not be mirrored by the normal mechanism and just WebKit's extra mirroring would create the correct result. I really hope someone at an influential Apple position would listen to me It really frustrates me to see Apple (who once was a pioneer in bidi and was one of the key founders of Unicode) in its current sad position in bidi support. The problems are deep rooted and want a real effort and will in high management positions to solve. - Hooman Mehr On Jun 12, 2004, at 7:51 PM, Behnam wrote: Short of missing something on the list, that would be me providing alternatives to Apple standard keyboards. But they are not fix of existing standards. In fact, they are not standard at all! But you are right. This is a minor issue and can be fixed. I can do it for Mac community but I rather ask Apple to do it in its original issue. My concern is more to do with different approaches in dealing with mirroring characters. The point being, it doesn't seem to be the way mirroring characters are mapped on MS keyboards. And most of the web-pages are typed by MS keyboards. Am I on the right track? Behnam On 12-Jun-04, at 10:54 AM, Hooman Mehr wrote: Hi, I checked it and can confirm that Apple's ISIRI 2901 keyboard has a bug in this regard. The Persian opening parenthesis in ISIRI 2901 is located on shit-0 and closing parenthesis on shift-9, but Apple's implementation have them reversed. This is a minor issue. The keyboard file is an XML file that can be easily edited with sys. admin. privileges. I think someone already posted information on a fixed and enhanced Persian Mac OS X keyboard on the list. - Hooman Mehr ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: khaat e Farsi
On Jun 11, 2004, at 9:01 AM, Peyman wrote: Conclusion: You can say that the origin of our alphabet is Arabic but you can not claim that our writing system is Arabic. Our writing system is Persian khaat e farsi. It is what my teacher Dr. Safavi as a linguist says in his book and what I also say as a linguist. Yes, sure. There is no argument with that. The only argument is what Arabic Script means in the context of Locale document. In that context, we are not talking about Khaat e Farsi but the name of the family of writing systems which are based on Arabic alphabet and its rules. Anybody with access to linguist know of a short common Persian term to use for the family of writing systems that use and extend Arabic alphabet and its basic rules. I don't think they call the quoted phrase Khaat e Farsi. Khaat e Farsi is a member of that group. - Hooman Mehr ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: Mirroring in Unicode
Hi, It is getting more interesting for me, because this is also one one the issues addressed by Persian GUI spec. document I am writing. Unfortunately, many people (including Microsoft) abuse Unicode when writing programs. They don't properly understand and observe bi-di semantics and the choices they make in places that Unicode is either silent or obscure results-in poor implementations. So, the problem is, Unicode specs and reports are not a substitute for good understanding of bi-di semantics, they are just regularizing some aspects of it. I also criticize Unicode organization for not being through enough in pointing out caveats in this regard and correctly giving the big picture. I know what I should do to get correct results because I have already discovered it independently. Unicode is just one way of putting some of that knowledge on paper and specifying certain methods to deal with certain issues without covering all issues. I would have never been able to think of a correct bi-di implementation solely from Unicode documents. So, what Unicode specifies is not wrong, but certainly it is not enough. Since there isn't a good documented source for specifying this kind of nuances in many aspects of handling bi-di text and Arabic Script, we came up with the idea of this Persian GUI spec to clarify these issues and provide guidelines to help developers implement correct Persian software (which includes correct bi-di behavior as a subset along with a lot of other things). If you are really interested in tackling these issues, contact me off list so that we can collaborate further on this. I don't see the list a suitable medium for the discussion because our discussion on this topic will get highly technical and interactive and we will need some diagrams to better illustrate it. So, it will confuse many list members who are not seasoned designers/developers. Just rest assured: The solution is there, clean and conclusive. Developers just need to get it. They can't easily get it (and it may take them years to get it like myself) because of the lack of good documentation. Persian GUI spec is an effort in the direction of clarifying the solutions to these issues. So, I repeat again: I need community support and help to produce something really helpful. Please take note that such an effort is in progress and it is related to a lot of these things, but it is still in early stages of being put on paper. Everything is still mostly in my head, help pull it out on paper in an understandable way. - Hooman Mehr On Jun 11, 2004, at 7:34 AM, Ordak D. Coward wrote: 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
Re: khaat e Farsi
ODC, Nice observation, I have been just repeating the typo without paying attention. I felt something is weird about the spelling but didn't notice the typo! Thank you. I have never been good at Penglish. On the other hand, Your arguments about the current generation of Arabic Script is valid and correct, but still misses the point: In the context of the locale document that has been the initial starting point for this discussion, Arabic Script is not considered from a linguistic history and evolution point of view. In that respect Kufi and Naskhi distinctions are quite valid. But it is not what we are talking about here. Let me give a concrete example. Russian and Tajik are written in Cyrillic script [1]. English and Turkish are written in Roman script. Persian and Arabic are written in (fill this with the correct word) script. So far, we have these suggestions (in Penglish): Farsi, Naskh, Arabi. I disagree with Farsi because it does not cover other family members. I accept that as a common mistake, informally people would call any script that resembles theirs as being Persian, but I don't know whether this should be accepted as the formal name as well. Also, some people argued that Arabic and Persian are different scripts. I don't want to go into that argument. From a pragmatic point of view, I am pointing out that the locale document is talking about a name that can be correctly used in the above context (when we are talking about the similarity of Arabic and Persian not their difference). I disagree with Naskh because it is easily confused with calligraphic style (the word is mostly used in that context if it appears after the word Khatt). Also it identifies the script from a different dimension/perspective than what is intended here. I can live with Arabi [2] but I don't really like it. Look at the other two examples above, Roman or Cyrillic on themselves are identifiable as being script names but Arabic is not. That is why I am still asking people to bring up new ideas. - Hooman Mehr [1] Script covers more than just alphabet (things like writing direction, baseline, etc) but should never be confused with language. Languages written with the same script may be totally unrelated. Also the same language may be written using different scripts in different regions, like Persian and its close cousin Tajik. [2] Arabi qualifies because it is the name of the language whose script is the root of the script used by the intended family of languages. On Jun 11, 2004, at 8:09 PM, Ordak D. Coward wrote: I am confused! Why people spell khaat with two a's? First I though it is a typo, but it seems everybody is writing it like that. Anyway, I think most people in Iran call the writing sytem khatt e faarsi even if to refers to an Arabic text. Furthermore, I still believe that khatt e koofee is not just a font, as it was very different from later khatts. There are lots of real samples at: http://www.mnh.si.edu/epigraphy/english_version/html/e_islamic.htm What makes khatt e koofee different from the current writing system is the number of characters. Another way of looking at it is to consider Kufi script a script where letters do not have dots. In my opinion, this by itself makes Kufi a different 'script' than modern Arabic. Now, I guess my original suggestion of Naskh is technically correct, if the following can add any weight to that choice: http://www.ancientscripts.com/arabic.html http://www.britannica.com/eb/article?eu=56293 Notice that khatt e naskh is called Naskhi script in English. -- ODC On Fri, 11 Jun 2004 14:46:37 +0430, Hooman Mehr [EMAIL PROTECTED] wrote: On Jun 11, 2004, at 9:01 AM, Peyman wrote: Conclusion: You can say that the origin of our alphabet is Arabic but you can not claim that our writing system is Arabic. Our writing system is Persian khaat e farsi. It is what my teacher Dr. Safavi as a linguist says in his book and what I also say as a linguist. Yes, sure. There is no argument with that. The only argument is what Arabic Script means in the context of Locale document. In that context, we are not talking about Khaat e Farsi but the name of the family of writing systems which are based on Arabic alphabet and its rules. Anybody with access to linguist know of a short common Persian term to use for the family of writing systems that use and extend Arabic alphabet and its basic rules. I don't think they call the quoted phrase Khaat e Farsi. Khaat e Farsi is a member of that group. - Hooman Mehr ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing ___ 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: UI problems in editing BiDi texts.
While we are at this topic: As I already mentioned, I am working on Persian GUI spec document [1]. One of the sizable portions of this document deals with this topic. If somebody wants to quickly start working on a new and improved implementation, please consult me to share my experience and early draft on the issue. Also, note that this issue is one of the single most important issues we need to solve in order to make using computers as easy for bi-di users as it is for Roman (or Latin) Script users. There is a lot of depth to this issue, don't try to come up with a quick idea and immediately think that you have solved it. It takes an expert in human computer interaction design. Someone in the same class as experts like Jeff Raskin, Bruce Tog Tognazzini, Donald A. Norman or Jakob Nielsen. Even then, we need extensive prototyping and user testing to refine the solution and select the best alternatives. Alright, I know, we don't live in an ideal world (or Iran) and we really can't expect to go after this issue in a really systematic way, but lets try to deal with it the best we can. - Hooman Mehr [1] If you have missed that post, look for Persian GUI Design Specifications Guidelines in the list archives. On Jun 9, 2004, at 3:01 AM, Ordak D. Coward wrote: 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 ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
[History] My Story, part 1 (1236 words)
. It took me working part time in a business environment, namely Sabir Co., [1] to realize the issue. It was 1988 in Sabir that I got introduced to Pishkar and Sayeh of Sina Soft [3]. Read their history in Shabakeh Monthly issue 39 [4] to get the outlook of Persian computing from an even older and different perspective. My involvement with Persian Computing as an influencer began with my career in Sibestan, the first independent marketing company of Apple Computer Inc. in Iran. The story of Sibestan is the subject of the next part. I can't promise when I'll write it, but I hope it will be soon. Endnotes: [1] Sabir is a government owned company specialized in dam construction. [2] What I am referring to as a character set is actually a glyph set. I am using the wrong term to emphasize how it was perceived then. The concept of glyph vs. character was unknown to most people at that time, including myself. [3] Pishkar was a basic word processor with support for a limited set of dot-matrix printers and was bundled with a hardware (an 8-bit ISA card) that would hack into the display ROM of the computer and replace the native character set with Pishkar character set -- or more accurately glyph set. A special hardware was needed for Persian support, because the commonly used graphics cards at that time (CGA, MDA, Hercules Mono.) couldn't handle downloaded display fonts. EGA cards were very expensive and usually implied a CRT upgrade. The card also doubled as the copy protection scheme for the software. So, they continued to bundle the card after EGA or even VGA cards became the norm. Sayeh was a later derivative that provided services for semi-transparent simple Persian input into existing DOS applications. The funny thing is that the glyph set in Sayeh was not fully compatible with that of Pishkar because of some limitations in the existing applications that couldn't deal with a couple of code points used in Pishkar's glyph set. The main difference between Pishkar/Sayeh glyph set and Iran System gyph set was that Iran System was strictly mono-spaced and one byte per glyph but Pishkar/Sayeh used special tail glyphs to better display wide glyphs (using two glyph parts). The reason that ultimately Iran System prevailed was its relative simplicity from a programmer's point of view. From a user's perspective, Pishkar/Sayeh solution was preferable because it was much more readable. [4] From a historical perspective, the articles in that issue are very interesting. I found out about them on the list (there was a post by Saber Soleimani). The articles are not officially online, and I am not aware of any other online options for obtaining it. If you are interested and don't have access to the articles, please let me know. - Hooman Mehr P.S.: Am I too far off topic? Too self centered? Please provide feedback. P.S. 2: Roozbeh, and other old-timers: How about starting to write down your own memories concerning history of Persian Computing as well? ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: Locale requirement of Persian in Iran, first public draft
On Jun 8, 2004, at 7:41 AM, C Bobroff wrote: By the way, I have received a PDF file from Iran recently in Persian and it was possible to copy and paste from the PDF text into Notepad and all the letters came out perfectly, only the letters were running backwards from left to right. I can't seem to copy and paste with yours. It ends up in garbage characters. Wish I knew these PDF secrets! Regarding PDFs: A PDF file only stores display glyphs (not characters) in left to right visual order and by definition can't do anything else. (It is intended to capture exact printout after all processing on the text is done.) For this reason, text extraction and search in PDFs in Arabic/Persian/etc is always a bit tricky. Although good Fonts and PDF viewer software can conceal that inherent complexity. In order for a PDF to be well formed for text search and extraction, font glyph names should conform to the old (90's) version of Adobe Glyph List glyph naming standard. Also, you should use a recent release of Acrobat Distiller (Not the PDFWriter virtual printer driver) to create the PDFs. This may involve additional complications such as first saving to a PostScript print file. PDFWriter can't work reliably because of the way Windows printer driver architecture works. So, don't expect PDFWriter to be fixed until say after Longhorn in 2006. The latest version of Acrobat Reader is somewhat improved in this regard, but to get something that works properly with well-formed PDFs, you will need Adobe Acrobat ME (Middle-East Edition). You can find more information on Adobe Central Europe/Middle East site: http://www.adobeceea.com/products/ME/main.html. They are claiming that the generic Reader 6 should search or copy text but actually only the 6.0 ME Acrobat Standard and Pro work properly and they are expensive if you just want to search or copy text... By the way, one of the potential places that we need a project Defined in FarsiLinux project is a Persian compatible PDF generator and viewer. - Hooman Mehr ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: [History] My Story, part 1 (1236 words)
On Jun 8, 2004, at 8:20 AM, C Bobroff wrote: Thank you, Hooman. [BTW, some of you may want to note the spelling of Hooman] Part 1 was great! I especially appreciated the Pre-history Thank you, too. If it wasn't for your insistence, I would never get myself into writing such things... By the way, I write the spelling of my name Hooman to help in correct pronunciation by foreigners. My name is exactly pronounced like two fused English words who-man. The spelling used by Roozbeh is the official spelling used on someone's passport -- if he does not insist otherwise. I insisted on Hooman spelling and got it even on my passport. - Hooman Mehr ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: Iranian Calendar (P.S.)
Hi Connie, OK, white flag up! I'll write some crime stories. But don't expect anything this week, I am very busy. Hooman On May 20, 2004, at 2:16 AM, C Bobroff wrote: Dear Hooman, I may move these stories to my pending weblog which hopefully will open in the next several days. Why should you move to your weblog? I can't think of a better place for the story of Persian computing than PersianComputing. One more thing, the reason that I may seem talented for story telling is that I am an INFP (http://www.personalitypage.com/INFP.html), so be-warned. Glad to know just what we're up against here! -Connie ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: Iranian Calendar (P.S.)
Hi Ordak, What you say makes perfect sense. I just didn't want to go into detail of everything in this regard. Suffice it so say, in such cases people come to agreement on establishing such authorities as part of their civil society. I vaguely hinted this in my post. Such an authority develops out of the needs of daily social life and as a normal (say democratic) civil authority and not a dictated sacred authority which could abuse its power by taking calendar hostage. Note that it gets very tricky for a religion to define and establish something. There is endless potential for abuse. People tend to put a sacred halo around it, and you know what happens next... So, the calendar authority is needed but religion is not in the right entity to establish it. When a religion needs to rely on a calendar, it needs to establish it in a way that the algorithm is very simple and accessible for ordinary people and ensure that it leaves the origin of the authority (or decision) with people so that they can delegate their right as they see fit. The fact that Iranian authorities in this regard act as if they are directly appointed by God is another story... Hooman On May 19, 2004, at 3:04 AM, Ordak D. Coward wrote: Dear Hooman, I am not trying to be annoyingly responsive, it is just a bad habit! What you said is fine, but I have to add that a calendar authority -- be it a person, a group, or just an algorithm -- is necessary in resolving conflicts in observation of the date and time. For example, if a contract between A and B requires A delivering a product to B at a certain date, then the two entities would need to choose an authority to resolve their confict in case of B's claim that A did not deliver on time. -- ODC On Tue, 18 May 2004 20:48:09 +0430, Hooman Mehr [EMAIL PROTECTED] wrote: On May 18, 2004, at 2:48 AM, C Bobroff wrote: On Mon, 17 May 2004, Hooman Mehr wrote: P.S.: Although Hijri calendar (and definition of the prayer times) look very strange and primitive, there is a very good philosophical reason behind it which makes sense once you know it. Do you know the reason or want to know it? Please continue. We are listening. You have a very nice narrative style! -Connie Hi Connie, Thank you for the nice complement. On a second thought, I got reluctant to discuss this matter on the list. It would be way off topic. Moreover, I am afraid that whatever I say could be interpreted as political statement or religious evangelism and start flamewars. Just to keep my word while trying to do minimal damage to the list, I'll write a paragraph: In original Islam, the definitions of calendar and prayer times are based on observation of simple natural phenomenon by ordinary human beings and assuring the individuals that their observation is valid and sufficient. The calendar authority is people, it comes from individual people with their personal observation, interpretation and judgment. Everybody can verify claims made by others. People usually voluntarily delegate this observation to a trustworthy group in a civil society. On the other hand, they may collaborate to ease the observation and get reassurance and support of others, while still keeping the final decision to themselves. This concept is closely related to some modern day concepts like human rights, diversity, democracy and freedom of information. To put it better in perspective, contrast this with the role of the religious calendars in ancient South American civilizations. Hooman Mehr ___ 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: Iranian Calendar (P.S.)
Dear Connie, Thank you very much for your interest and support. I will try to start talking about such things soon. I may move these stories to my pending weblog which hopefully will open in the next several days. When I start the weblog I will announce it here. Although my limited time may prevent me from posting often. One more thing, the reason that I may seem talented for story telling is that I am an INFP (http://www.personalitypage.com/INFP.html), so be-warned. Hooman On May 19, 2004, at 10:24 AM, C Bobroff wrote: On Tue, 18 May 2004, Hooman Mehr wrote: On a second thought, I got reluctant to discuss this matter on the list. It would be way off topic. Moreover, I am afraid that whatever I say could be interpreted as political statement or religious evangelism and start flamewars. Looks like Fortune smiled upon you and you managed to post without getting flamed. So, with this newly acquired confidence and since you have some talent in story-telling, are you going to please tell us about your past crimes soon? Nimrooz, etc? I mean, from the beginning and please don't skimp on the details. I think I'm not the only one who would love to hear it! -Connie ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: Iranian Calendar
Hi Omid and Connie, MSDN way of specifying Hijri calendar is like saying the length of any month in Gregorian calendar is 30 days plus or minus two days -- true but not very useful. Alright my example is grossly exaggerated, but I mean to highlight my point. The official Iranian Islamic Calendar is computed by a body called Showraa-ye Aalie-e Taghvim (quoting Roozbeh's spelling). It comes up with an initial estimate (or best guess) of the *adjusted* calendar which is usually only re-adjusted for Ramadan. This pre-adjusted calendar is not the same as the basic table in MSDN, nor the mostly observational Hijri calendar meant by MSDN and common in Saudi Arabia. You can verify my assertion by looking at the published calendars for the past few years and see that it does not match perfectly. To be honest, the last time I checked was more than 10 years ago and I no longer have the specifics, so I'll be glad to see it verified again to see if there is any changes in how that mysterious chamber calculates it. On the other hand, you can come up with good research work in academia around the world in this regard (like the link Omid mentions), but none of them will be the official Iranian Islamic Calendar even if it matches the past history of the printed calendars perfectly. This is the same funny (or sad) issue already raised for 2820-year Birashk calendar. As a result, I am against treating this calendar to be the same as Hijri calendar with MSDN definition or any none official academic definition, even if the difference would be one day in 50 years. Algorithmic calculation of a pre-adjusted Hijri calendar is potentially way more complicated than Birashk calendar and is always less precise, so there is more potential for variation among the different bodies calculating it. It is affected by exact geographic coordinates (not just time-zone), height of the location, neighboring ground texture (being water, mountains, etc.), relative position of sun and earth or in common terms season (seasons in the Hijri calendar rotate, so that the same month is sometimes in mid-summer and sometimes in mid-winter) and atmospheric visibility, which is a momentary condition and impossible to calculate, only possible to statistically estimate. And I am not even beginning to talk about the human observer as another key factor... If we want to strictly adhere to its true (religious) definition, even the best guess will be meaningless without actual observation. In Saudi this is the case with their religious Hijri calendar, they may adjust each month based on official[see endnote] observation. Note: Observation along with some rules (to cover bad weather) define this calendar not calculation. This is not the case in Iran where the best guess of the mentioned official body (regardless of the algorithm they are using) is considered good enough except for Ramadan where again we have the definition based on official observation. Please note that a good calendar software service in an operating system or application should be able to tell you precisely what was the date say 100,000 days ago at a specific location (within the range of validity of the calendar, of course) or what date it estimates to be at a specific location 100,000 days in the future. Naturally, the more confident the future estimate the better, but some calendar systems simply don't permit this by their very definition. I don't know the approach taken by the contractors for the calendar project in FarsiLinux, can someone comment on this? Hooman Mehr [Endnote: Official observer and official observation address the issue of the observer which affects the resulting calendar.] P.S.: Although Hijri calendar (and definition of the prayer times) look very strange and primitive, there is a very good philosophical reason behind it which makes sense once you know it. Do you know the reason or want to know it? On May 17, 2004, at 12:52 AM, Omid K. Rad wrote: On Sun, 16 May 2004, C Bobroff wrote: > > On Sun, 16 May 2004, Hooman Mehr wrote: > > > The lunar Hijri calendar used in Iran is also an official calendar and > > is calculated independent from other Hijri calendars used in other > > islamic countries. It is an important calendar, since it determines > > half of the holidays on our calendar. We also know that it has > > slightly different month lengths than other Hijri calendars. > > Are there any online or downloadable calendars or converters > for the lunar Hijri system used in Iran? I'm only hearing > about this different month lenghts business today... > > -Connie I don't think there is any difference in month lenghts either. This Java applet base on the Calendarical Calculations book is the best online application I've seen for converting dates: http://emr.cs.iit.edu/home/reingold/calendar-book/second-edition/CIIT.html Omid ___ PersianComputing maili
Re: Iranian Calendar
Hi, Thank you for the refinements and clarifications. Maybe I've used to the old Mac OS calendar API which used to correctly support dates way before Gregorian calendar existed (even before Christian era). On the other hand, even if you reduce my suggested number to 2000 days, you'll find differences and it won't be unreasonable to expect an OS to support it. On May 17, 2004, at 8:05 PM, Roozbeh Pournader wrote: On Mon, 2004-05-17 at 11:55, Hooman Mehr wrote: It comes upwith an initial estimate (or best guess) of the *adjusted* calendarwhich is usually only re-adjusted for Ramadan. ... and Shawwal. This pre-adjustedcalendar is not the same as the basic table in MSDN, nor the mostlyobservational Hijri calendar meant by MSDN and common in Saudi Arabia. The Microsoft Hijri base calendar is acutally based on the Kuwaiti one. I guess I saw it on the Wikipedia, but I can find the reference if it proves to be important. Please note that a good calendar software service in an operatingsystem or application should be able to tell you precisely what wasthe date say 100,000 days ago at a specific location (within the rangeof validity of the calendar, of course) or what date it estimates tobe at a specific location 100,000 days in the future. I don't agree. An operating system rarely allows any date calculation for 270 years into the past or the future. Even for Gregorian. roozbeh ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: Iranian Calendar
Hi Behdad, I have a question (targeting you and everybody else working on Persian locale projects such as .Net) The lunar Hijri calendar used in Iran is also an official calendar and is calculated independent from other Hijri calendars used in other islamic countries. It is an important calendar, since it determines half of the holidays on our calendar. We also know that it has slightly different month lengths than other Hijri calendars. Are you going to identify and support that calendar as well? Then what would you call it in English? The answer to this question may affect Iranian Calendar term as well. If you ask me, we can keep Iranian Calendar and call the Hijri calendar Iranian Secondary Calendar or Iranian Religious Calendar or something like that. I think we should avoid solar / lunar designations in the English name to make it more meaningful and less confusing for none-Iranians. With the same logic one may suggest using Iranian Primary Calendar instead of Iranian Calendar to emphasize the fact that more than one official regional calendar exists in Iran. My final verdict? I need to sleep on it for a while. Hooman Mehr On May 15, 2004, at 2:36 PM, Behdad Esfahbod wrote: Hi, Just trying to close an item in the long open agenda of the list. So we've reached a consensus on using Iranian Calendar for the term referring to the solar calendar in action in Tehran, right? So we forget about Jalali name, and call it Iranian Calendar, quite like Chinese, Japanese, and other countries. As for the rules, we at FarsiWeb have found enough evidence that the 2820-year periodic calendar of Birashk. We will later release the codes for that and replace our different ports. Please send your comments. Hamed, you are supposed to work on this, right? Thanks, --behdad behdad.org ___ 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: Iranian Calendar
Hi Behdad, Very good. Agreed to Iranian Calendar and Iranian Islamic Calendar. Hooman On May 17, 2004, at 12:01 AM, Behdad Esfahbod wrote: Hi Hooman, Thanks for the question. I go with Iranian Islamic Calendar. I think Primary/Secondary and Solar/Lunar are both very bad names. And Islamic makes sense since that's what this calendar is called in English, so ours is the *Iranian* Islamic Calendar. And then Iranian Calendar and Iranian Islamic Calendar should be clear enough that which one's primary and which secondary. behdad On Sun, 16 May 2004, Hooman Mehr wrote: Hi Behdad, I have a question (targeting you and everybody else working on Persian locale projects such as .Net) The lunar Hijri calendar used in Iran is also an official calendar and is calculated independent from other Hijri calendars used in other islamic countries. It is an important calendar, since it determines half of the holidays on our calendar. We also know that it has slightly different month lengths than other Hijri calendars. Are you going to identify and support that calendar as well? Then what would you call it in English? The answer to this question may affect Iranian Calendar term as well. If you ask me, we can keep Iranian Calendar and call the Hijri calendar Iranian Secondary Calendar or Iranian Religious Calendar or something like that. I think we should avoid solar / lunar designations in the English name to make it more meaningful and less confusing for none-Iranians. With the same logic one may suggest using Iranian Primary Calendar instead of Iranian Calendar to emphasize the fact that more than one official regional calendar exists in Iran. My final verdict? I need to sleep on it for a while. Hooman Mehr On May 15, 2004, at 2:36 PM, Behdad Esfahbod wrote: Hi, Just trying to close an item in the long open agenda of the list. So we've reached a consensus on using Iranian Calendar for the term referring to the solar calendar in action in Tehran, right? So we forget about Jalali name, and call it Iranian Calendar, quite like Chinese, Japanese, and other countries. As for the rules, we at FarsiWeb have found enough evidence that the 2820-year periodic calendar of Birashk. We will later release the codes for that and replace our different ports. Please send your comments. Hamed, you are supposed to work on this, right? Thanks, --behdad behdad.org ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing ___ 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
Persian GUI Design Specifications Guidelines
Hi All, Although this is my first post, I have been lurking around this list for quite a while now. For those who don't know me, let me put a not so short intro about myself: I am one of those old guys in Persian computing. I've been around with Persian software issues, localization, globalization, standards and even Persian screen and typographic fonts since 1989 (1368). As an example, look at Nimrooz font (the father of Nesf et. al), ISIRI 3342 and 2901 and you'll find some evidence leading to my past crimes... I started getting involved in the above issues on Apple's Mac OS platform which is still my favorite. Then I got driven to many platforms from OS/400 to various UNIXes and Linux (Windows being a given). To know how far I date back, it is enough to mention I've been seriously exposed to a CDC-6000 and later NCR's Decision Mate 5. (Trivia quiz: Who knows what are the latter two?) Aside from Iran I have also worked in Persian Gulf region, Europe and Australia in various kinds of IT projects from RPG to Java, Objective-C and Mono/.NET with a lot of things in between, like 4D (www.4D.com). Right now, I am proudly residing in my home country and still involved in detailed technical work including coding. I am running Gentoo Linux 2004.0 on Mac and Fedora on PC, but most of my daily work (this e-mail included) is done on Mac OS X Panther which (despite seriously lacking in Persian Computing) is simply irresistible... OK, now finally to the subject of the post: I have the honor of being chosen by FarsiLinux management to work on their Persian GUI Design Specifications Guidelines project. I am also guilty of supporting the project since its conception which lead to its approval, albeit with generous support of Roozbeh and others. I will try to keep this community informed about the progress of this project and gather early feedback to improve the quality of the final result. I will set up a site or blog to post early information. I'll announce it hopefully by mid next week. To help you know how to best flame me, first read the RFP of the project here: http://www.farsilinux.org/DownloadCenter/rpfs/PersianHIG-821220.zip Seriously, I welcome early thoughts before I start influencing your train of thought with my own. I'll also be glad to answer questions you may have related to purpose and scope of the project. Let me be frank with you, I am getting paid (very modestly) for doing this and you are not, but don't let this turn you off. The project may have an important impact on everything related to Persian Computing, not just Persian Linux. Lets try to make this project a positive step towards a better era in Persian computing. On the other hand, I can use a helping hand as a part-time assistant in some specific areas. Mail me off-list if you are interested. Apologies for my tedious writing style (typical traditional Persian!) and taking so much of your time/bandwidth and thank you for reading this far. Hooman Mehr ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
