Re: Personal names survey
On Sat, 2004-06-19 at 00:32, C Bobroff wrote: I'm so glad you also now see that to *forbid* marking ezaafe in personal names is absurd. Connie, Please! You really don't see the point? We are not documenting practice in the locale spec, we are *specifying* a single way to do things. People are very welcome to ignore the specification and do whatever they like to do, if they don't claim they follow it. roozbeh ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
Re: khatt e Farsi
On Fri, 2004-06-18 at 21:49, Peyman wrote: After resolving this issue, I try to go through the nice draft and give my suggestions if any. We would appreciate suggestions, independent of whether this issue gets resolved or not. roozbeh ___ 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: [Persian Locale d6 Feedback] Short Format Dates
On Sat, 2004-06-19 at 18:41, Hooman Mehr wrote: [...] 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. That will be specified in a coming appendix, which will have the locale data for ICU and GNU C library. Anyway, the situation is worse than what you may guess. The Unicode Consortium has changed the bidirectional category of a few characters, including Slash, in Unicode 4.0.1. For Slash and its brethren, it's not just Neutral or things like that. We are having stuff like European Terminators and Common Separators in the Unicode Bidi algorithm. 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). I'm not implying anything about users here. We are specifying how the final text should be displayed. We have not specified how to encode it (of course that doesn't mean one is allowed to encode it however he likes). If we do that, we may not remain conforming to Unicode if Unicode changes yet another bidirectional category in a later version. 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. I always do the right thing, don't I? ;-) Alright I know, you may say: It is impossible any other way! What is the solution? I say: the answer is too technical to be included in the locale specification. There will be different answers for different situations, in different contexts, or in different Unicode versions. BTW, Behdad is attending the Unicode Consortium's Technical Committee meeting right now, and later the ISO JTC1/SC2 ones. I'm sure the UTC meeting (which will be the first with a FarsiWeb member present) will have good news for us (which may include more changes and clarifications to the Bidirectional algorithm). roozbeh ___ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
