Bangla(Bengali) letter Missing
Hi everyone, I am a Bangladeshi. Bangladesh is a country to the east of India. Bangla is our national language. Recently I checked the unicode standard 3.0 and found that a letter that is frequently used in Bangla is absent from the standard. It is Bangla letter Khondo-ta. . Can anyone tell me whether this letter is being considered for inclusion (I assume that some other might have proposed for its inclusion). If not what can I do to propose its inclusion. My second headache is that Bangla should be used in the unicode standard instead of Bengali. Bengali is misspelled so. Originali all bangali's (in West bengal and Bangladesh) spell it as Bangla. What can I do to correct the spelling ? Thanks every body. Md Ziaur Rahman khonda-ta.bmp
Re: Unicode has included the Inscriptions of Harappa/Mohenjadaro/Egypt...?
Actually, they have not yet been added. The following is from http://www.unicode.org/unicode/standard/where/ "...for example, Egyptian hieroglyphs have not yet been encoded because there is not yet general agreement on the exact repertoire of characters." michka - Original Message - From: "Padma kumar .R" <[EMAIL PROTECTED]> To: "Unicode List" <[EMAIL PROTECTED]> Sent: Wednesday, July 26, 2000 10:08 PM Subject: Unicode has included the Inscriptions of Harappa/Mohenjadaro/Egypt...? > Hi, > > I am very much interested 2 know about whether the old inscriptions on > harappa, mohenjadaro, sumaria, egypt and like things are included in the > unicode list... if so, are there any document of how to use or pronounce > atleast some of the characters... and are there any fonts that supports > this If you know please let me know it... i am deeply interested in > this area... > > by > - padmakumar.r > ([EMAIL PROTECTED]) >
Unicode has included the Inscriptions of Harappa/Mohenjadaro/Egypt...?
Hi, I am very much interested 2 know about whether the old inscriptions on harappa, mohenjadaro, sumaria, egypt and like things are included in the unicode list... if so, are there any document of how to use or pronounce atleast some of the characters... and are there any fonts that supports this If you know please let me know it... i am deeply interested in this area... by - padmakumar.r ([EMAIL PROTECTED])
Re: Euro
> >Have people started hand-writing the euro, yet? I wonder how this > >complies with EU regulation that prescribes a precise glyph design > >for the symbol. Will people need to go around with compass and > >rule to write cheques? > > It seems improbable that the prescribed design (which includes blue > and yellow color specifications as well) is intended for general > use. Aside from a couple general-purpose symbol fonts, every font I > know of which includes the Euro* has modified it to match the rest > of the typeface. The only problem is that font companies (probably from non-EU countries) use a `C' glyph with two horizontal bars, not recognizing that the origin of the Euro glyph is a Greek small epsilon. Werner
Re: Spanish Locales
There is another problem with using the defaulting of "es" to mean Latin America, which is that there are *other* things that locales do besides text. Ideally, you want to see the particular currency, date format, etc. for the specific locale, while not having to have twenty-seven copies of the same resource bundle. The two-bundle solution also allows some weird special things (like having the support information for the "About" dialog stored in the specific bundle for the specific locale, while having most of the UI in the "LA Spanish" bundle). This way your application looks even MORE localized! Another backdoor solution is to create a ResourceBundle that contains a class that loads the UI from another set of resources. This avoids having the list of locales in the first example (and lets you put specific locale-based strings in the "upper level" bundle). Regards, Addison === Addison P. PhillipsPrincipal Consultant Inter-Locale LLChttp://www.inter-locale.com Los Gatos, CA, USA mailto:[EMAIL PROTECTED] +1 408.210.3569 (mobile) +1 408.904.4762 (fax) === Globalization Engineering & Consulting Services On Wed, 26 Jul 2000, Tex Texin wrote: > Linus, thanks. > > Yes, that was among the first ideas we had, but I don't like leaving it to > customers to have to edit their configurations and often they > don't realize that the configuration is editable and just presume the vendor > doesn't support their market well. > > Also, I am not sure how many countries besides Spain, and outside of > Latin America of course, might use Iberian Spanish. Anyone know? > tex > > Linus Toshihiro Tanaka wrote: > > > > My suggestion is to use "es" for Latin American Spanish, and "es_ES" for > > Iberian Spanish. If some Spanish speaking countries prefer Iberian > > Spanish, then you could copy the contents from "es_ES" (to "es_PH", for > > example). This way, you can probably reduce the number of files from > > 20(?) to a few (or several) files. If some countries really want > > different contents, then you could create new contents (for "es_MX", for > > example). > > > > ++ > > | Linus Toshihiro Tanaka500 Oracle Parkway M/S 4op7 | > > | NLS Consulting Team Redwood Shores, CA 94065 USA | > > | Server Globalization Technology email: [EMAIL PROTECTED] | > > | Oracle Corporation | > > ++ > > -- > If practice makes perfect, and nobody's perfect, why practice? > > Tex Texin Director, International Products > mailto:[EMAIL PROTECTED] +1-781-280-4271 Fax:+1-781-280-4655 > Progress Software Corp.14 Oak Park, Bedford, MA 01730 > > http://www.progress.com#1 Embedded Database > http://www.SonicMQ.com JMS Messaging- Best Middleware Award > http://www.aspconnections.com #1 provider in the ASP marketplace > http://www.NuSphere.comOpen Source software and services for MySQL > > Globalization Programhttp://www.progress.com/partners/globalization.htm > - > Come to the Panel on Open Source Approaches to Unicode Libraries > at the Sept. Unicode Conference http://www.unicode.org/iuc/iuc17 >
Fwd: First ICU Developer Workshop Survey
This is an open invitation for people interested in the ICU Unicode library. markus Original Message From: "Helena Shih" <[EMAIL PROTECTED]> Subject: First ICU Developer Workshop Survey Hi everyone. The ICU project management committee (PMC) is planning to host a two-day ICU developer's meeting this coming September right after the Unicode conference. The purpose of this workshop meeting is to provide an opportunity for the new or seasoned ICU users to learn more about the current ICU features, design goals/architecture, future directions and so on. The workshop is currently scheduled for September 11 and 12 and the location will be in Cupertino, California, USA. In order to better design an agenda that will satisfy most people, I'd like to ask those who are interested in coming to the workshop to fill out the attached survey (in both Word and HTML format) before we complete the final workshop agenda. Please submit the survey by the end of day, August 4th. You can either email the survey back to me at [EMAIL PROTECTED] or fax it to +1 408-777-5890. If you have any other suggestions or comments, please also feel free to add them to the document before submitting it. Once the survey request is completed, more details on the workshop is to follow shortly. Look forward to hearing from you. Regards, Helena Shih == First International Components for Unicode Developer Workshop September 11-12, 2000 Cupertino, California Session Survey Name: __ Title: ___ Company: ___ Email: __ Work Phone Number: __ Work Address: ___ The purpose of this survey is to design a complete ICU workshop agenda that will better assist the ICU users to understand the ICU technologies and proper deployment of the ICU Unicode support in their products. General Information Please let us know which ICU components you would like to learn more about. Please write a number from 1 to 9 in the order of the subjects that you are interested in, 1 being the highest and 9 the lowest. [ ] Basic Unicode Support including Unicode character properties , UnicodeString and iterator interface [ ] Locale and Resource Management including ResourceBundle [ ] Data Accessing Mechanism and Packaging Facilities [ ] Date/Time Handling including Timezone and Calendar support [ ] Character Set Conversion [ ] Formatting and Parsing Number, Time/Date and Messages [ ] Transformation Support including transliteration, normalization, Bidi and case mapping [ ] Searching and Sorting [ ] Text Analysis including boundary detection Beginners Level Please check off the sessions and topics that you are most interested of. [ ] Basic i18n/Unicode Understanding: [ ] What are UTF8, UTF-16 and UTF-32? [ ] How are they different from UCS-2 and UCS-4? [ ] What are the common character encoding schemes? [ ] Why is a glyph not necessarily equal to a character? [ ] What kinds of Unicode character property information are provided in ICU? [ ] What are the string related interfaces in ICU and how and when to use them? [ ] Others, please specify. [ ] ICU Overall Feature Summary: [ ] What are the features and support of the current version of ICU? [ ] Why should I care about them? [ ] When do I use what feature and tell me briefly how. [ ] Others, please specify. [ ] ICU Design and Architecture: [ ] What are the basic architectures that are common to ICU and Java i18n support? [ ] How are system resources localized? [ ] What is the threading model? [ ] How to extend the implementation to include my own code? [ ] Whats the error handling model? [ ] Others, please specify. [ ] Install and Build/Port Process: [ ] How do I build ICU on Windows and UNIX environments? [ ] What are the options to configure an ICU build? [ ] What resource files are necessary to integrate ICU into my product? [ ] What problems I may run into while porting ICU to a new platform? [ ] Others, please specify. [ ] Application Level Extensibility: [ ] What are the common pitfalls in migrating my product to u
Re: Spanish Locales
Linus, thanks. Yes, that was among the first ideas we had, but I don't like leaving it to customers to have to edit their configurations and often they don't realize that the configuration is editable and just presume the vendor doesn't support their market well. Also, I am not sure how many countries besides Spain, and outside of Latin America of course, might use Iberian Spanish. Anyone know? tex Linus Toshihiro Tanaka wrote: > > My suggestion is to use "es" for Latin American Spanish, and "es_ES" for > Iberian Spanish. If some Spanish speaking countries prefer Iberian > Spanish, then you could copy the contents from "es_ES" (to "es_PH", for > example). This way, you can probably reduce the number of files from > 20(?) to a few (or several) files. If some countries really want > different contents, then you could create new contents (for "es_MX", for > example). > > ++ > | Linus Toshihiro Tanaka500 Oracle Parkway M/S 4op7 | > | NLS Consulting Team Redwood Shores, CA 94065 USA | > | Server Globalization Technology email: [EMAIL PROTECTED] | > | Oracle Corporation | > ++ -- If practice makes perfect, and nobody's perfect, why practice? Tex Texin Director, International Products mailto:[EMAIL PROTECTED] +1-781-280-4271 Fax:+1-781-280-4655 Progress Software Corp.14 Oak Park, Bedford, MA 01730 http://www.progress.com#1 Embedded Database http://www.SonicMQ.com JMS Messaging- Best Middleware Award http://www.aspconnections.com #1 provider in the ASP marketplace http://www.NuSphere.comOpen Source software and services for MySQL Globalization Programhttp://www.progress.com/partners/globalization.htm - Come to the Panel on Open Source Approaches to Unicode Libraries at the Sept. Unicode Conference http://www.unicode.org/iuc/iuc17
RE: Digits (Was: What a difference a glyph makes...)
. . . and still another digit one, non-tabular, for fine typography. And, of course, there are the old-style digits. Don // -Original Message- From: Valeriy E. Ushakov [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 26, 2000 3:19 PM To: Unicode List Subject: Digits (Was: What a difference a glyph makes...) On Wed, Jul 26, 2000 at 12:02:15 -0800, [EMAIL PROTECTED] wrote: > This reminds me of "Are DIGIT SEVEN and DIGIT SEVEN > WITH STROKE distinct characters?" Yeah, our decimal > number system has at least thirteen digits: > DIGIT ONE Add another ONE here: digit one with bottom stroke: /| _|_ This bottom stroke in ONE was mandatory, just like slashed zero, for submitting punching jobs (you know, in those batch days when punched cards were still in active use and you had an option to submit a handwritten text of your program to be punched for you). SY, Uwe -- [EMAIL PROTECTED] | Zu Grunde kommen http://www.ptc.spbu.ru/~uwe/| Ist zu Grunde gehen
Re: Spanish Locales
My suggestion is to use "es" for Latin American Spanish, and "es_ES" for Iberian Spanish. If some Spanish speaking countries prefer Iberian Spanish, then you could copy the contents from "es_ES" (to "es_PH", for example). This way, you can probably reduce the number of files from 20(?) to a few (or several) files. If some countries really want different contents, then you could create new contents (for "es_MX", for example). ++ | Linus Toshihiro Tanaka500 Oracle Parkway M/S 4op7 | | NLS Consulting Team Redwood Shores, CA 94065 USA | | Server Globalization Technology email: [EMAIL PROTECTED] | | Oracle Corporation | ++
Re: Spanish Locales
I agree that the approach he outlined would be best for the actual division you may find that two locales with perhaps some reviewers for markets you care about will suffice. michka - Original Message - From: "Tex Texin" <[EMAIL PROTECTED]> To: "Michael (michka) Kaplan" <[EMAIL PROTECTED]> Cc: "Unicode List" <[EMAIL PROTECTED]> Sent: Wednesday, July 26, 2000 3:46 PM Subject: Re: Spanish Locales > Thanks. I think the adequacy of one region's dialect for another market > perhaps depends on which vertical markets your application is for. > Different verticals get influenced from different directions. > Also it changes over time. > > I like Addison's idea. If I introduce a mapping mechanism in between the > operating system locale setting and my software's locale then I can > stop fretting over whether a coup somewhere will cause me to reconfigure > my product line. > > tex > > > "Michael (michka) Kaplan" wrote: > > > > My personal feeling is that for most purposes, you can get away with a > > single American Spanish (as opposed to European Spanish) that would cover > > South and Latin America. > > > > Microsoft (for Windows 2000) renamed LCID 3082's name from Modern Spanish to > > International Spanish, which is the only language they localize product into > > when it comes to Spanish. However, there are many important differences > > between the two and many of my Mexican friends (including the lady who > > localizes my web site) definitely can tell the difference, and I have even > > had people complain at times about the "Mexican Spanish" being used without > > being specified as such. > > > > Even in the Latin American countries, there can be issues. Slogans such as > > "Wouldn't you like a car today" are fine most places with "carro" but in > > Guatemala they would indeed wonder why you want them to have a pig today. > > :-) > > > > The general MS feeling on stuff like this is to pick a locale to use as your > > base, and then just make sure that you have people who can review to pick up > > problems like the usage of carro (use coche instead!) and such. This is what > > they do with English and Spanish (where they use 1033 which is US English, > > and then either 1034 or 3082 depending on the product, to cover a wide range > > of locales (Spanish has a LOT of LCIDs!). They do the same with Arabic, > > using 1025 (which is their LCID for Arabic - Saudia Arabia) for all Arabic > > locales (there are lots of them, too!). > > > > I think their plan works, within reason. I have friends in Morocco who are > > not fond of the Arabic versions of MS products any more than my Mexican > > friends are of the Spanish ones. This all boils down to how much you can > > invest in a market, mostly. > > > > michka > > > > - Original Message - > > From: "Tex Texin" <[EMAIL PROTECTED]> > > To: "Unicode List" <[EMAIL PROTECTED]> > > Sent: Wednesday, July 26, 2000 2:50 PM > > Subject: Spanish Locales > > > > > I wonder how others are dealing with problems like the > > > following: > > > > > > I have a Java program for which I also have a translation for Latin > > America. > > > I know there are differences among the Latin American dialects, but I am > > > told this file is ok for all Latin America. At the same time it is not > > > for use in Spain, so I have a different file for that. > > > > > > I have not found a locale for Latin America. I am reluctant to create > > > locales for each country in L.A. as I guess it is too likely I will > > > get it wrong, and it also increases the disk footprint of the program. > > > > > > I do not want to simply make this translation the default (es), as I am > > > concerned I do not know all of the places where the preferred language is > > > Castillian Spanish, and for these I would need to make an exception. > > > > > > Any good ways around this, or do I need to simply bite the bullet and > > > make one variation for every country. > > > > > > tex > > > > > > -- > > > If practice makes perfect, and nobody's perfect, why practice? > > > -- > > -- > > > Tex Texin Director, International Products > > > mailto:[EMAIL PROTECTED] +1-781-280-4271 Fax:+1-781-280-4655 > > > Progress Software Corp.14 Oak Park, Bedford, MA 01730 > > > > > > http://www.progress.com#1 Embedded Database > > > http://www.SonicMQ.com JMS Messaging- Best Middleware Award > > > http://www.aspconnections.com #1 provider in the ASP marketplace > > > http://www.NuSphere.comOpen Source software and services for MySQL > > > > > > Globalization Program > > http://www.progress.com/partners/globalization.htm > > > -- > > --- > > > Come to the Panel on Open Source Approaches to Unicode Libraries > > > at the Sept. Unicode Conference http://www.unicode.org/iuc/iuc17 > > > > > -- > If practice makes perfect
Re: Spanish Locales
Thanks. I think the adequacy of one region's dialect for another market perhaps depends on which vertical markets your application is for. Different verticals get influenced from different directions. Also it changes over time. I like Addison's idea. If I introduce a mapping mechanism in between the operating system locale setting and my software's locale then I can stop fretting over whether a coup somewhere will cause me to reconfigure my product line. tex "Michael (michka) Kaplan" wrote: > > My personal feeling is that for most purposes, you can get away with a > single American Spanish (as opposed to European Spanish) that would cover > South and Latin America. > > Microsoft (for Windows 2000) renamed LCID 3082's name from Modern Spanish to > International Spanish, which is the only language they localize product into > when it comes to Spanish. However, there are many important differences > between the two and many of my Mexican friends (including the lady who > localizes my web site) definitely can tell the difference, and I have even > had people complain at times about the "Mexican Spanish" being used without > being specified as such. > > Even in the Latin American countries, there can be issues. Slogans such as > "Wouldn't you like a car today" are fine most places with "carro" but in > Guatemala they would indeed wonder why you want them to have a pig today. > :-) > > The general MS feeling on stuff like this is to pick a locale to use as your > base, and then just make sure that you have people who can review to pick up > problems like the usage of carro (use coche instead!) and such. This is what > they do with English and Spanish (where they use 1033 which is US English, > and then either 1034 or 3082 depending on the product, to cover a wide range > of locales (Spanish has a LOT of LCIDs!). They do the same with Arabic, > using 1025 (which is their LCID for Arabic - Saudia Arabia) for all Arabic > locales (there are lots of them, too!). > > I think their plan works, within reason. I have friends in Morocco who are > not fond of the Arabic versions of MS products any more than my Mexican > friends are of the Spanish ones. This all boils down to how much you can > invest in a market, mostly. > > michka > > - Original Message - > From: "Tex Texin" <[EMAIL PROTECTED]> > To: "Unicode List" <[EMAIL PROTECTED]> > Sent: Wednesday, July 26, 2000 2:50 PM > Subject: Spanish Locales > > > I wonder how others are dealing with problems like the > > following: > > > > I have a Java program for which I also have a translation for Latin > America. > > I know there are differences among the Latin American dialects, but I am > > told this file is ok for all Latin America. At the same time it is not > > for use in Spain, so I have a different file for that. > > > > I have not found a locale for Latin America. I am reluctant to create > > locales for each country in L.A. as I guess it is too likely I will > > get it wrong, and it also increases the disk footprint of the program. > > > > I do not want to simply make this translation the default (es), as I am > > concerned I do not know all of the places where the preferred language is > > Castillian Spanish, and for these I would need to make an exception. > > > > Any good ways around this, or do I need to simply bite the bullet and > > make one variation for every country. > > > > tex > > > > -- > > If practice makes perfect, and nobody's perfect, why practice? > > -- > -- > > Tex Texin Director, International Products > > mailto:[EMAIL PROTECTED] +1-781-280-4271 Fax:+1-781-280-4655 > > Progress Software Corp.14 Oak Park, Bedford, MA 01730 > > > > http://www.progress.com#1 Embedded Database > > http://www.SonicMQ.com JMS Messaging- Best Middleware Award > > http://www.aspconnections.com #1 provider in the ASP marketplace > > http://www.NuSphere.comOpen Source software and services for MySQL > > > > Globalization Program > http://www.progress.com/partners/globalization.htm > > -- > --- > > Come to the Panel on Open Source Approaches to Unicode Libraries > > at the Sept. Unicode Conference http://www.unicode.org/iuc/iuc17 > > -- If practice makes perfect, and nobody's perfect, why practice? Tex Texin Director, International Products mailto:[EMAIL PROTECTED] +1-781-280-4271 Fax:+1-781-280-4655 Progress Software Corp.14 Oak Park, Bedford, MA 01730 http://www.progress.com#1 Embedded Database http://www.SonicMQ.com JMS Messaging- Best Middleware Award http://www.aspconnections.com #1 provider in the ASP marketplace http://www.NuSphere.comOpen Source software and services for MySQL Globalization Programhttp
Re: Spanish Locales
Addison, thanks. Seems very reasonable. I owe you a beer! ;-) tex [EMAIL PROTECTED] wrote: > > Hi Tex, > > There is a not-all-that-straightforward method that I've seen which > might fit your needs. > > First: establish your resource bundle locale as separate from the > currently active locale (e.g. have a variable for your resource locale and > use it to explicitly load the resources rather than using the program > locale and letting Java determine locale for you). This will allow you to > control the loading of the resource bundle YOU WANT to be associated with > a specific locale. > > Second: Create a resource bundle called "ResourceLocale.properties" in the > format: > > = > > where locale_installed is the name of the installed locale (like es_EC for > Ecuador) and locale_to_use is the name of the locale of the resource > bundle you'd like to contain the messages (es_CO for Latin America, for > example). This sounds awful, but there are only 144 installed locales in > JDK 1.3 (cf. http://www.inter-locale.com/demos/locales.jsp), at least on > Linux that's the number... and you only have to do it once. > > It is not performance enhancing, but it does provide a quick-and-dirty way > of getting around the problem you describe. That way "es" can be whichever > variant you prefer and the defaulting mechanism still works for things > like NumberFormet and the like. In any case, it makes some sense to > control bundle loading like this anyway, because there are some vague > cases in the locale model (like LA Spanish). > > You may also find that you need TWO resource bundle sets, one with > localizable strings (e.g. locale_to_use) and one with locale-related > strings that are not for localization (e.g. the regular resource bundle). > > The downside to this solution is that it makes code devilishly difficult > to read (by comparison) and can confuse developers (who have to remember > what goes where). > > Regards, > > Addison > > === > Addison P. PhillipsPrincipal Consultant > Inter-Locale LLChttp://www.inter-locale.com > Los Gatos, CA, USA mailto:[EMAIL PROTECTED] > > +1 408.210.3569 (mobile) +1 408.904.4762 (fax) > === > Globalization Engineering & Consulting Services > > On Wed, 26 Jul 2000, Tex Texin wrote: > > > I wonder how others are dealing with problems like the > > following: > > > > I have a Java program for which I also have a translation for Latin America. > > I know there are differences among the Latin American dialects, but I am > > told this file is ok for all Latin America. At the same time it is not > > for use in Spain, so I have a different file for that. > > > > I have not found a locale for Latin America. I am reluctant to create > > locales for each country in L.A. as I guess it is too likely I will > > get it wrong, and it also increases the disk footprint of the program. > > > > I do not want to simply make this translation the default (es), as I am > > concerned I do not know all of the places where the preferred language is > > Castillian Spanish, and for these I would need to make an exception. > > > > Any good ways around this, or do I need to simply bite the bullet and > > make one variation for every country. > > > > tex > > > > -- > > If practice makes perfect, and nobody's perfect, why practice? > > > > Tex Texin Director, International Products > > mailto:[EMAIL PROTECTED] +1-781-280-4271 Fax:+1-781-280-4655 > > Progress Software Corp.14 Oak Park, Bedford, MA 01730 > > > > http://www.progress.com#1 Embedded Database > > http://www.SonicMQ.com JMS Messaging- Best Middleware Award > > http://www.aspconnections.com #1 provider in the ASP marketplace > > http://www.NuSphere.comOpen Source software and services for MySQL > > > > Globalization Programhttp://www.progress.com/partners/globalization.htm > > - > > Come to the Panel on Open Source Approaches to Unicode Libraries > > at the Sept. Unicode Conference http://www.unicode.org/iuc/iuc17 > > -- If practice makes perfect, and nobody's perfect, why practice? Tex Texin Director, International Products mailto:[EMAIL PROTECTED] +1-781-280-4271 Fax:+1-781-280-4655 Progress Software Corp.14 Oak Park, Bedford, MA 01730 http://www.progress.com#1 Embedded Database http://www.SonicMQ.com JMS Messaging- Best Middleware Award http://www.aspconnections.com #1 provider in the ASP marketplace http://www.NuSphere.comOpen Source software and services for MySQL Globalization Programhttp://www.progress.com/partn
Re: Spanish Locales
My personal feeling is that for most purposes, you can get away with a single American Spanish (as opposed to European Spanish) that would cover South and Latin America. Microsoft (for Windows 2000) renamed LCID 3082's name from Modern Spanish to International Spanish, which is the only language they localize product into when it comes to Spanish. However, there are many important differences between the two and many of my Mexican friends (including the lady who localizes my web site) definitely can tell the difference, and I have even had people complain at times about the "Mexican Spanish" being used without being specified as such. Even in the Latin American countries, there can be issues. Slogans such as "Wouldn't you like a car today" are fine most places with "carro" but in Guatemala they would indeed wonder why you want them to have a pig today. :-) The general MS feeling on stuff like this is to pick a locale to use as your base, and then just make sure that you have people who can review to pick up problems like the usage of carro (use coche instead!) and such. This is what they do with English and Spanish (where they use 1033 which is US English, and then either 1034 or 3082 depending on the product, to cover a wide range of locales (Spanish has a LOT of LCIDs!). They do the same with Arabic, using 1025 (which is their LCID for Arabic - Saudia Arabia) for all Arabic locales (there are lots of them, too!). I think their plan works, within reason. I have friends in Morocco who are not fond of the Arabic versions of MS products any more than my Mexican friends are of the Spanish ones. This all boils down to how much you can invest in a market, mostly. michka - Original Message - From: "Tex Texin" <[EMAIL PROTECTED]> To: "Unicode List" <[EMAIL PROTECTED]> Sent: Wednesday, July 26, 2000 2:50 PM Subject: Spanish Locales > I wonder how others are dealing with problems like the > following: > > I have a Java program for which I also have a translation for Latin America. > I know there are differences among the Latin American dialects, but I am > told this file is ok for all Latin America. At the same time it is not > for use in Spain, so I have a different file for that. > > I have not found a locale for Latin America. I am reluctant to create > locales for each country in L.A. as I guess it is too likely I will > get it wrong, and it also increases the disk footprint of the program. > > I do not want to simply make this translation the default (es), as I am > concerned I do not know all of the places where the preferred language is > Castillian Spanish, and for these I would need to make an exception. > > Any good ways around this, or do I need to simply bite the bullet and > make one variation for every country. > > tex > > -- > If practice makes perfect, and nobody's perfect, why practice? > -- -- > Tex Texin Director, International Products > mailto:[EMAIL PROTECTED] +1-781-280-4271 Fax:+1-781-280-4655 > Progress Software Corp.14 Oak Park, Bedford, MA 01730 > > http://www.progress.com#1 Embedded Database > http://www.SonicMQ.com JMS Messaging- Best Middleware Award > http://www.aspconnections.com #1 provider in the ASP marketplace > http://www.NuSphere.comOpen Source software and services for MySQL > > Globalization Program http://www.progress.com/partners/globalization.htm > -- --- > Come to the Panel on Open Source Approaches to Unicode Libraries > at the Sept. Unicode Conference http://www.unicode.org/iuc/iuc17 >
Re: Spanish Locales
Hi Tex, There is a not-all-that-straightforward method that I've seen which might fit your needs. First: establish your resource bundle locale as separate from the currently active locale (e.g. have a variable for your resource locale and use it to explicitly load the resources rather than using the program locale and letting Java determine locale for you). This will allow you to control the loading of the resource bundle YOU WANT to be associated with a specific locale. Second: Create a resource bundle called "ResourceLocale.properties" in the format: = where locale_installed is the name of the installed locale (like es_EC for Ecuador) and locale_to_use is the name of the locale of the resource bundle you'd like to contain the messages (es_CO for Latin America, for example). This sounds awful, but there are only 144 installed locales in JDK 1.3 (cf. http://www.inter-locale.com/demos/locales.jsp), at least on Linux that's the number... and you only have to do it once. It is not performance enhancing, but it does provide a quick-and-dirty way of getting around the problem you describe. That way "es" can be whichever variant you prefer and the defaulting mechanism still works for things like NumberFormet and the like. In any case, it makes some sense to control bundle loading like this anyway, because there are some vague cases in the locale model (like LA Spanish). You may also find that you need TWO resource bundle sets, one with localizable strings (e.g. locale_to_use) and one with locale-related strings that are not for localization (e.g. the regular resource bundle). The downside to this solution is that it makes code devilishly difficult to read (by comparison) and can confuse developers (who have to remember what goes where). Regards, Addison === Addison P. PhillipsPrincipal Consultant Inter-Locale LLChttp://www.inter-locale.com Los Gatos, CA, USA mailto:[EMAIL PROTECTED] +1 408.210.3569 (mobile) +1 408.904.4762 (fax) === Globalization Engineering & Consulting Services On Wed, 26 Jul 2000, Tex Texin wrote: > I wonder how others are dealing with problems like the > following: > > I have a Java program for which I also have a translation for Latin America. > I know there are differences among the Latin American dialects, but I am > told this file is ok for all Latin America. At the same time it is not > for use in Spain, so I have a different file for that. > > I have not found a locale for Latin America. I am reluctant to create > locales for each country in L.A. as I guess it is too likely I will > get it wrong, and it also increases the disk footprint of the program. > > I do not want to simply make this translation the default (es), as I am > concerned I do not know all of the places where the preferred language is > Castillian Spanish, and for these I would need to make an exception. > > Any good ways around this, or do I need to simply bite the bullet and > make one variation for every country. > > tex > > -- > If practice makes perfect, and nobody's perfect, why practice? > > Tex Texin Director, International Products > mailto:[EMAIL PROTECTED] +1-781-280-4271 Fax:+1-781-280-4655 > Progress Software Corp.14 Oak Park, Bedford, MA 01730 > > http://www.progress.com#1 Embedded Database > http://www.SonicMQ.com JMS Messaging- Best Middleware Award > http://www.aspconnections.com #1 provider in the ASP marketplace > http://www.NuSphere.comOpen Source software and services for MySQL > > Globalization Programhttp://www.progress.com/partners/globalization.htm > - > Come to the Panel on Open Source Approaches to Unicode Libraries > at the Sept. Unicode Conference http://www.unicode.org/iuc/iuc17 >
Digits (Was: What a difference a glyph makes...)
On Wed, Jul 26, 2000 at 12:02:15 -0800, [EMAIL PROTECTED] wrote: > This reminds me of "Are DIGIT SEVEN and DIGIT SEVEN > WITH STROKE distinct characters?" Yeah, our decimal > number system has at least thirteen digits: > DIGIT ONE Add another ONE here: digit one with bottom stroke: /| _|_ This bottom stroke in ONE was mandatory, just like slashed zero, for submitting punching jobs (you know, in those batch days when punched cards were still in active use and you had an option to submit a handwritten text of your program to be punched for you). SY, Uwe -- [EMAIL PROTECTED] | Zu Grunde kommen http://www.ptc.spbu.ru/~uwe/| Ist zu Grunde gehen
RE: What a difference a glyph makes...
At 10:33 AM 7/26/2000 -0800, Alistair Vining wrote: >Have people started writing the Euro with only one bar yet? The issue is, >after all, rapidly disappearing for the Irish and Italians. I've seen one typeface with a single-barred Euro, but most of my colleagues seem to agree that this is a bad idea. When we're hinting TT for low resolutions, however, we usually collapse the two bars into one somewhere around 9ppm. John Hudson Tiro Typeworks Vancouver, BC www.tiro.com [EMAIL PROTECTED]
Spanish Locales
I wonder how others are dealing with problems like the following: I have a Java program for which I also have a translation for Latin America. I know there are differences among the Latin American dialects, but I am told this file is ok for all Latin America. At the same time it is not for use in Spain, so I have a different file for that. I have not found a locale for Latin America. I am reluctant to create locales for each country in L.A. as I guess it is too likely I will get it wrong, and it also increases the disk footprint of the program. I do not want to simply make this translation the default (es), as I am concerned I do not know all of the places where the preferred language is Castillian Spanish, and for these I would need to make an exception. Any good ways around this, or do I need to simply bite the bullet and make one variation for every country. tex -- If practice makes perfect, and nobody's perfect, why practice? Tex Texin Director, International Products mailto:[EMAIL PROTECTED] +1-781-280-4271 Fax:+1-781-280-4655 Progress Software Corp.14 Oak Park, Bedford, MA 01730 http://www.progress.com#1 Embedded Database http://www.SonicMQ.com JMS Messaging- Best Middleware Award http://www.aspconnections.com #1 provider in the ASP marketplace http://www.NuSphere.comOpen Source software and services for MySQL Globalization Programhttp://www.progress.com/partners/globalization.htm - Come to the Panel on Open Source Approaches to Unicode Libraries at the Sept. Unicode Conference http://www.unicode.org/iuc/iuc17
Euro (was: What a difference a glyph makes...)
At 11:01 AM -0800 7/26/00, [EMAIL PROTECTED] wrote: >Have people started hand-writing the euro, yet? I wonder how this complies >with EU regulation that prescribes a precise glyph design for the symbol. >Will people need to go around with compass and rule to write cheques? It seems improbable that the prescribed design (which includes blue and yellow color specifications as well) is intended for general use. Aside from a couple general-purpose symbol fonts, every font I know of which includes the Euro* has modified it to match the rest of the typeface. If the EU decides this is somehow invalid, they'll find that people will keep using it in any but the most official contexts, because switching fonts to get the official version is a pain. - David Lemon * Something around 1000 fonts at this point
RE: What a difference a glyph makes...
This reminds me of "Are DIGIT SEVEN and DIGIT SEVEN WITH STROKE distinct characters?" Yeah, our decimal number system has at least thirteen digits: DIGIT ZERO DIGIT ZERO WITH STROKE DIGIT ONE DIGIT TWO DIGIT THREE CLOSED DIGIT FOUR OPEN DIGIT FOUR DIGIT FIVE DIGIT SIX DIGIT SEVEN DIGIT SEVEN WITH STROKE DIGIT EIGHT DIGIT NINE -- Robert Lozyniak Accusplit pedometer, purchased about 2000a07l01d19h45mZ, has NOT FLIPPED My page: http://walk.to/11 [EMAIL PROTECTED] - email (917) 421-3909 x1133 - voicemail/fax "Alistair Vining" <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > > > Notice to British and Irish Unicoders: > > > > U+00A3 (POUND SIGN) is a cursive "L" with *one* > bar > > through it (cmp. http://charts.unicode.org/Web/U0080.html). > > U+20A4 (LIRA SIGN) is a cursive "L" with *two* > bars > > through it (cmp. http://charts.unicode.org/Web/U20A0.html). > > > > Please, watch out carefully your next tax form, > and remember > > who posted this. > > I assume you're joking here (the internet irony > firewall is still up). An L > with two bars is an acceptable glyph for UK pounds > as well. They're both > the same (libra) sign. Or are you saying that > an L with one bar would be > (completely) unacceptable for (Italian) lire? > > Have people started writing the Euro with only > one bar yet? The issue is, > after all, rapidly disappearing for the Irish and > Italians. > > Al. > > > ___ Get your own FREE Bolt Onebox - FREE voicemail, email, and fax, all in one place - sign up at http://www.bolt.com
[OT] RE: What a difference a glyph make
Alistair Vining wrote: > I assume you're joking here (the internet irony firewall is > still up). An L > with two bars is an acceptable glyph for UK pounds as well. > They're both > the same (libra) sign. Or are you saying that an L with one > bar would be > (completely) unacceptable for (Italian) lire? I am semi-serious and, personally, I agree with your statement. But the one-bar and two-bar glyph is the only visible difference between the two characters in the Unicode charts. Of course, "Unicode encodes abstract characters, not glyphs", but as the dollar/peso history teaches, there are cases when you have to be careful using the "wrong" glyph. Moreover, if not for the different glyph, I can see no reason why the Italian and Turkish currencies have one code point, while the British and Irish currencies have another. After all both symbols, as you say, were actually the abbreviation of Latin "libra", that means "pound" (in weight: "lb."). And all four currencies above are called the same in some languages (e.g., "lira" in Italian: "lira italiana, lira turca, lira sterlina, lira irlandese"). BTW, apart hand-written prices in road markets (where the sign normally has *two* bars), none of these symbols is currently used in Italy (we rather use "Lit"). I suspect this is because the Italian government knows Italians, and wanted to avoid anybody having the idea of paying taxes in Turkish currency... > Have people started writing the Euro with only one bar yet? > The issue is, > after all, rapidly disappearing for the Irish and Italians. Have people started hand-writing the euro, yet? I wonder how this complies with EU regulation that prescribes a precise glyph design for the symbol. Will people need to go around with compass and rule to write cheques? _ Marco
RE: What a difference a glyph makes...
[EMAIL PROTECTED] wrote: > > Notice to British and Irish Unicoders: > > U+00A3 (POUND SIGN) is a cursive "L" with *one* bar > through it (cmp. http://charts.unicode.org/Web/U0080.html). > U+20A4 (LIRA SIGN) is a cursive "L" with *two* bars > through it (cmp. http://charts.unicode.org/Web/U20A0.html). > > Please, watch out carefully your next tax form, and remember > who posted this. I assume you're joking here (the internet irony firewall is still up). An L with two bars is an acceptable glyph for UK pounds as well. They're both the same (libra) sign. Or are you saying that an L with one bar would be (completely) unacceptable for (Italian) lire? Have people started writing the Euro with only one bar yet? The issue is, after all, rapidly disappearing for the Irish and Italians. Al.
Re: Unicode keyboard editor utility
You might also want to check out Keyboard Layout Manager at http://solair.eunet.yu/~minya/Programs/klm/klm.html which allows redefinition of keyboard mapping files for most Windows systems (Win9x, NT, 2K). Hope this helps, Vladimir Alan Wood wrote: > Magda Danish asked if anyone knew of a Unicode keyboard editor utility. > There is a beta release of version 5.0 of Keyboard Manager that supports > Unicode characters and works with Windows NT. It can be downloaded from > http://www.tavultesoft.com/keyman/. > Janko's Keyboard Generator is for Windows 95 and 98, and does not seem to > support Unicode. http://solair.eunet.yu/~janko/engdload.htm > I have recently come across 3-D Keyboard, but I have not had time to > investigate it. http://www.fingertipsoft.com/3dkbd/index.html > > When I get time, I will add the latter 2 to my page of font and keyboard > utilities at: > http://www.hclrss.demon.co.uk/unicode/utilities_fonts.html > > Alan Wood > (Documentation Writer / Web Master) > Context Limited > (Electronic publishers of UK and EU legal and official documents) > mailto:[EMAIL PROTECTED] > http://www.context.co.uk/ > http://www.alanwood.net/ (Unicode, special characters, pesticide names) -- Vladimir Weinstein Software Engineer, Unicode Technology Group IBM JTC Cupertino 408-777-5844 (t/l 240-5844)
Re: U+2121
On Tue, 25 Jul 2000 18:28:25 -0800 (GMT-0800), Patrick Andries ([EMAIL PROTECTED]) wrote: >Shoudl the telephone sign U+2121 be superscript, and therefore annotated > 0054 T 0045 E 004C L. Nope. The "TEL" sign depicted on page 508 of the Unicode 3.0 Book isn't superscript (unliken say, the immediately preceding and following characters, U+2120 SERVICE MARK and U+2122 TRADE MARK SIGN). Also, the description on page 509 indicates a compatibility decomposition to U+0054 U+0045 U+004C without a compatibility formatting tag. >The two only Unicode fonts I have show this character as a superscript glyph >(Andalé and Arial Unicode MS). A quick check with the two fonts on my mac that have this character in their repertoire (Osaka and Heisei Mincho) reveals a somewhat condensed (but *not* superscript) "TEL". -- marco -- I have forced myself to contradict myself, in order to avoid conforming to my own taste.
Re: What a difference a glyph makes...
Interestingly for tax forms, the fallback mapping for many Windows encodings has Lira (₤) converting up to pound (£), cf. http://oss.software.ibm.com/icu/charset/CharMaps-HTML/windows-1252-2000.html. There are some other interesting fallbacks there... Mark [EMAIL PROTECTED] wrote: > Mark Davis wrote: > > [...] A dollar sign with only one bar through the S, he said, is > > used only by several South American currencies, and thus he is now > > paid in full. [...] > > Notice to British and Irish Unicoders: > > U+00A3 (POUND SIGN) is a cursive "L" with *one* bar through it (cmp. > http://charts.unicode.org/Web/U0080.html). U+20A4 (LIRA SIGN) is a cursive > "L" with *two* bars through it (cmp. > http://charts.unicode.org/Web/U20A0.html). > > Please, watch out carefully your next tax form, and remember who posted > this. > > _ Marco
Re: U+2121
Patrick Andries asked: > Shoudl the telephone sign U+2121 be superscript, and therefore annotated > 0054 T 0045 E 004C L. No. U+2121 was given a compatibility decomposition involving for Unicode versions 1.1.5, 2.0.0, and 2.1.2. This was based primarily on the source representation for the character in XCCS (1990 version) which showed the character superscripted. However, during the deliberations regarding data file specifications that led to the 2.1.5 update, the UTC specifically considered U+2121 and decided that unlike the service mark (U+2120) and the trademark (U+2122), which are always shown superscripted, the TELEPHONE SIGN was not treated that way, and the was changed to . (The actual change occurred between the unreleased versions 2.1.3 and 2.1.4, but showed up publicly in the 2.1.5 update version.) > > The two only Unicode fonts I have show this character as a superscript glyph > (Andalé and Arial Unicode MS). The reason for this is that many existing fonts were modeled in part on how characters were displayed in Unicode 2.0, and the designation in that document influenced font design decisions. The official UTC position on this is that for U+2121, superscript appearance is not distinctive, and an lowline or midline glyph representation would be just as appropriate. There is a reason the editorial committee highlighted the disclaimer now printed on page 331 at the very beginning of the Code Charts chapter of Unicode 3.0. --Ken
RE: What a difference a glyph makes...
Mark Davis wrote: > [...] A dollar sign with only one bar through the S, he said, is > used only by several South American currencies, and thus he is now > paid in full. [...] Notice to British and Irish Unicoders: U+00A3 (POUND SIGN) is a cursive "L" with *one* bar through it (cmp. http://charts.unicode.org/Web/U0080.html). U+20A4 (LIRA SIGN) is a cursive "L" with *two* bars through it (cmp. http://charts.unicode.org/Web/U20A0.html). Please, watch out carefully your next tax form, and remember who posted this. _ Marco
Re: Unicode in VFAT file system
Actually, the problem is the *same old thing*: no education about I18N issues in general. There are all sorts of interesting "biases" about Unicode related to the still lamentable level of I18N training that the average developer receives. It's simply shocking. Best regards, Addison On Wed, 26 Jul 2000, Michael (michka) Kaplan wrote: > Ah, I did know that! :-) > > The place I find a UTF-8 bias most often is in people doing web content and > people working with Oracle. Good to know there are others with UCS-2/UTF-16 > biases! > > And of course its even better when we get them to accept that they are > mainly different ways of expressing the same thing. > > michka >
Re: SQL Server and Unicode
The latest Microsoft JDBC/ODBC driver appears to work. I say appears because I haven't really used it for more than a quick test. Of course, this driver is a Windows-only phenomenon. Hope this helps. Addison === Addison P. PhillipsPrincipal Consultant Inter-Locale LLChttp://www.inter-locale.com Los Gatos, CA, USA mailto:[EMAIL PROTECTED] +1 408.210.3569 (mobile) +1 408.904.4762 (fax) === Globalization Engineering & Consulting Services On Wed, 26 Jul 2000, Michael (michka) Kaplan wrote: > Unfortunately, Java and especially JDBC is one of those places where I > cannot even maintain the illusion of "knowing everything". :-) > > >From colleagues of mine who work in the UNIX/Java sphere, the impression I > have gotten is that many/most of the JDBC stuff was done prior to SQL 7.0, > and thus had no Unicode fields to run against. This makes them always > convert using some code page (probably using the non-Unicode SQLS scheme > which is to base it off the collation choice of the server, which until 7.0 > was actually the ideal plan). > > I would hope that my (limited) knowledge is obsolete and that work has been > done to make things work in SQLS 7.0 and 2000 Unicode fields through JDBC. > Can someone confirm or deny this? > > michka > > > - Original Message - > From: "Tex Texin" <[EMAIL PROTECTED]> > To: "Michael (michka) Kaplan" <[EMAIL PROTECTED]> > Cc: "Unicode List" <[EMAIL PROTECTED]> > Sent: Wednesday, July 26, 2000 8:49 AM > Subject: Re: SQL Server and Unicode > > > > Michael, > > Do you know of JDBC drivers that support using > > queries and updates of UCS-2 (or UTF-16) text in the SQL Server database? > > > > I am having trouble confirming which ones support this and have confirmed, > > that > > even though Java is Unicode-based, some of the drivers only work provided > > the text is to be converted to some code page other than Unicode for > storage > > and retrieval on the database. > > > > tex > > > > > > "Michael (michka) Kaplan" wrote: > > > > > > SQL Server supports the datatypes NTEXT, NCHAR, and NVARCHAR, all of > which > > > are of type UCS-2. When such a column indexed, then the index is Unicode > (I > > > am not sure if this what you mean). > > > > > > SQL Server 7.0 only supports one language collation at the server > level > > > this choice affects the actual ordering of all such indexes. > > > > > > SQL Server 2000 supports a COLLATE keyword that allows you to specify a > > > collation at the database or field level and thus choose a different > > > language for such columns/indexes if you like (I discuss practical > details > > > and implications of this feature in an upcoming article in the Visual > Basic > > > Programmer's Journal, tentatively scheduled for November). > > > > > > In any case, you can certainly query and such field in either SQL 7.0 or > in > > > SQL 2000. > > > > > > Hopefully this answers your question; if not, let me know. :-) > > > > > > michka > > > > > > - Original Message - > > > From: "pierre vaures" <[EMAIL PROTECTED]> > > > To: "Unicode List" <[EMAIL PROTECTED]> > > > Sent: Wednesday, July 26, 2000 1:23 AM > > > Subject: SQL Server and Unicode > > > > > > > To Whom It May Concern: > > > > > > > > > > > > SQL server is in the Unicode Products WebSite described as Unicode > > > enables. > > > > > > > > What we would like to know is : > > > > > > > > a - Does SQL Server allows to set as an index a field in Unicode > standard? > > > > b - Can you make SQL query on this particular field? > > > > > > > > If you have any information, or ideas, thanks for your help. > > > > > > > > Regards, > > > > > > > > Pierre > > > > > > > > -- > > If practice makes perfect, and nobody's perfect, why practice? > > -- > -- > > Tex Texin Director, International Products > > mailto:[EMAIL PROTECTED] +1-781-280-4271 Fax:+1-781-280-4655 > > Progress Software Corp.14 Oak Park, Bedford, MA 01730 > > > > http://www.progress.com#1 Embedded Database > > http://www.SonicMQ.com JMS Messaging- Best Middleware Award > > http://www.aspconnections.com #1 provider in the ASP marketplace > > http://www.NuSphere.comOpen Source software and services for MySQL > > > > Globalization Program > http://www.progress.com/partners/globalization.htm > > -- > --- > > Come to the Panel on Open Source Approaches to Unicode Libraries > > at the Sept. Unicode Conference http://www.unicode.org/iuc/iuc17 > > > >
RE: What a difference a glyph makes...
> -Original Message- > From: Mark Davis [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, July 26, 2000 11:03 AM > To: Unicode List > Subject: What a difference a glyph makes... > > From "News of the Wierd" > http://www.mercurycenter.com/premium/ent/docs/weird726.htm > > In 1999, James Weber of Calgary, Alberta, paid his tax bill > (equivalent to about $75,000 U.S.) dollar-for-dollar with Colombian > pesos (worth about $50 U.S.), arguing that the Canada Customs and > Revenue Agency failed to print its dollar signs with two bars through > the ``S.'' A dollar sign with only one bar through the S, he said, is > used only by several South American currencies, and thus he is now > paid in full. (In March 2000, an appeals court ruled against him, > despite his having produced several favorable historical banking > documents from as far back as 1910.) [Hohberger, Clive] But there is another story there, too. As a amateur numismatist myself, I believe that the 2-line "$' issue here comes from the fact that in the mid-1800s there was a US coin which had a stylized narrow "U" overprinted on an "S" as a "US" logo. Over the years it became a 2-line "$" which is rarley, if ever used outside the US Clive
What a difference a glyph makes...
>From "News of the Wierd" http://www.mercurycenter.com/premium/ent/docs/weird726.htm In 1999, James Weber of Calgary, Alberta, paid his tax bill (equivalent to about $75,000 U.S.) dollar-for-dollar with Colombian pesos (worth about $50 U.S.), arguing that the Canada Customs and Revenue Agency failed to print its dollar signs with two bars through the ``S.'' A dollar sign with only one bar through the S, he said, is used only by several South American currencies, and thus he is now paid in full. (In March 2000, an appeals court ruled against him, despite his having produced several favorable historical banking documents from as far back as 1910.)
Re: SQL Server and Unicode
Unfortunately, Java and especially JDBC is one of those places where I cannot even maintain the illusion of "knowing everything". :-) >From colleagues of mine who work in the UNIX/Java sphere, the impression I have gotten is that many/most of the JDBC stuff was done prior to SQL 7.0, and thus had no Unicode fields to run against. This makes them always convert using some code page (probably using the non-Unicode SQLS scheme which is to base it off the collation choice of the server, which until 7.0 was actually the ideal plan). I would hope that my (limited) knowledge is obsolete and that work has been done to make things work in SQLS 7.0 and 2000 Unicode fields through JDBC. Can someone confirm or deny this? michka - Original Message - From: "Tex Texin" <[EMAIL PROTECTED]> To: "Michael (michka) Kaplan" <[EMAIL PROTECTED]> Cc: "Unicode List" <[EMAIL PROTECTED]> Sent: Wednesday, July 26, 2000 8:49 AM Subject: Re: SQL Server and Unicode > Michael, > Do you know of JDBC drivers that support using > queries and updates of UCS-2 (or UTF-16) text in the SQL Server database? > > I am having trouble confirming which ones support this and have confirmed, > that > even though Java is Unicode-based, some of the drivers only work provided > the text is to be converted to some code page other than Unicode for storage > and retrieval on the database. > > tex > > > "Michael (michka) Kaplan" wrote: > > > > SQL Server supports the datatypes NTEXT, NCHAR, and NVARCHAR, all of which > > are of type UCS-2. When such a column indexed, then the index is Unicode (I > > am not sure if this what you mean). > > > > SQL Server 7.0 only supports one language collation at the server level > > this choice affects the actual ordering of all such indexes. > > > > SQL Server 2000 supports a COLLATE keyword that allows you to specify a > > collation at the database or field level and thus choose a different > > language for such columns/indexes if you like (I discuss practical details > > and implications of this feature in an upcoming article in the Visual Basic > > Programmer's Journal, tentatively scheduled for November). > > > > In any case, you can certainly query and such field in either SQL 7.0 or in > > SQL 2000. > > > > Hopefully this answers your question; if not, let me know. :-) > > > > michka > > > > - Original Message - > > From: "pierre vaures" <[EMAIL PROTECTED]> > > To: "Unicode List" <[EMAIL PROTECTED]> > > Sent: Wednesday, July 26, 2000 1:23 AM > > Subject: SQL Server and Unicode > > > > > To Whom It May Concern: > > > > > > > > > SQL server is in the Unicode Products WebSite described as Unicode > > enables. > > > > > > What we would like to know is : > > > > > > a - Does SQL Server allows to set as an index a field in Unicode standard? > > > b - Can you make SQL query on this particular field? > > > > > > If you have any information, or ideas, thanks for your help. > > > > > > Regards, > > > > > > Pierre > > > > > -- > If practice makes perfect, and nobody's perfect, why practice? > -- -- > Tex Texin Director, International Products > mailto:[EMAIL PROTECTED] +1-781-280-4271 Fax:+1-781-280-4655 > Progress Software Corp.14 Oak Park, Bedford, MA 01730 > > http://www.progress.com#1 Embedded Database > http://www.SonicMQ.com JMS Messaging- Best Middleware Award > http://www.aspconnections.com #1 provider in the ASP marketplace > http://www.NuSphere.comOpen Source software and services for MySQL > > Globalization Program http://www.progress.com/partners/globalization.htm > -- --- > Come to the Panel on Open Source Approaches to Unicode Libraries > at the Sept. Unicode Conference http://www.unicode.org/iuc/iuc17 >
Re: Making Unicode characters
If you just want one or two characters, I have a chart webpage on my site (www.macchiato.com). You type in the code number and ENTER, and it presents a chart of 128 characters, with that character in green. Copy and paste, and here it is. 女 [Visible if your mailer handles UTF-8] Mark [EMAIL PROTECTED] wrote: > >How do I make U+5973, for instance? I want to make > >it so I can see it on the screen. I want to do that > >without cheating by e.g. using Paint. > > What do you mean my "make"? Invent it? Already done. Create a font with an > appropriate glyph? Go buy Fontographer, FontLab or RoboFog. Get it into > your document? Well, there's lots of ways to skin that cat, one of them > being to fire up you're favourite programming tool, bone up on the > appropriate DDK, and write a keyboard driver. Or stay tuned for something > like Keyman 5 from Tavultesoft. > > >Magda, if you're in programming, make it (the keyboard > >utility) yourself. > > Why are we picking on Magda? > > - Peter > > --- > Peter Constable > > Non-Roman Script Initiative, SIL International > 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA > Tel: +1 972 708 7485 > E-mail: <[EMAIL PROTECTED]>
Re: Making Unicode characters
To give examples: In VB? Use ChrW$(&H5973). In VBScript? Use ChrW(&H5973) In HTML? Use In JScript/JavaScript? Use \u5973 and so on. The answer is 100% dependent on where you are trying to show the character. michka - Original Message - From: <[EMAIL PROTECTED]> To: "Unicode List" <[EMAIL PROTECTED]> Sent: Tuesday, July 25, 2000 6:13 PM Subject: Making Unicode characters > How do I make U+5973, for instance? I want to make > it so I can see it on the screen. I want to do that > without cheating by e.g. using Paint. > > Magda, if you're in programming, make it (the keyboard > utility) yourself. Only you're not, right? > > -- > Robert Lozyniak > Accusplit pedometer, purchased about 2000a07l01d19h45mZ, > has NOT FLIPPED > My page: http://walk.to/11 > [EMAIL PROTECTED] - email > (917) 421-3909 x1133 - voicemail/fax > > > > ___ > Get your own FREE Bolt Onebox - FREE voicemail, email, and > fax, all in one place - sign up at http://www.bolt.com > >
errata! Re: Unicode in VFAT file system
> Ah, I did know that! :-) Oops, I meant "Ah, I did *not* know that! Mea culpa. michka
Re: SQL Server and Unicode
Michael, Do you know of JDBC drivers that support using queries and updates of UCS-2 (or UTF-16) text in the SQL Server database? I am having trouble confirming which ones support this and have confirmed, that even though Java is Unicode-based, some of the drivers only work provided the text is to be converted to some code page other than Unicode for storage and retrieval on the database. tex "Michael (michka) Kaplan" wrote: > > SQL Server supports the datatypes NTEXT, NCHAR, and NVARCHAR, all of which > are of type UCS-2. When such a column indexed, then the index is Unicode (I > am not sure if this what you mean). > > SQL Server 7.0 only supports one language collation at the server level > this choice affects the actual ordering of all such indexes. > > SQL Server 2000 supports a COLLATE keyword that allows you to specify a > collation at the database or field level and thus choose a different > language for such columns/indexes if you like (I discuss practical details > and implications of this feature in an upcoming article in the Visual Basic > Programmer's Journal, tentatively scheduled for November). > > In any case, you can certainly query and such field in either SQL 7.0 or in > SQL 2000. > > Hopefully this answers your question; if not, let me know. :-) > > michka > > - Original Message - > From: "pierre vaures" <[EMAIL PROTECTED]> > To: "Unicode List" <[EMAIL PROTECTED]> > Sent: Wednesday, July 26, 2000 1:23 AM > Subject: SQL Server and Unicode > > > To Whom It May Concern: > > > > > > SQL server is in the Unicode Products WebSite described as Unicode > enables. > > > > What we would like to know is : > > > > a - Does SQL Server allows to set as an index a field in Unicode standard? > > b - Can you make SQL query on this particular field? > > > > If you have any information, or ideas, thanks for your help. > > > > Regards, > > > > Pierre > > -- If practice makes perfect, and nobody's perfect, why practice? Tex Texin Director, International Products mailto:[EMAIL PROTECTED] +1-781-280-4271 Fax:+1-781-280-4655 Progress Software Corp.14 Oak Park, Bedford, MA 01730 http://www.progress.com#1 Embedded Database http://www.SonicMQ.com JMS Messaging- Best Middleware Award http://www.aspconnections.com #1 provider in the ASP marketplace http://www.NuSphere.comOpen Source software and services for MySQL Globalization Programhttp://www.progress.com/partners/globalization.htm - Come to the Panel on Open Source Approaches to Unicode Libraries at the Sept. Unicode Conference http://www.unicode.org/iuc/iuc17
Re: Unicode in VFAT file system
That's not true. Even serious UNIX shops start with the perception that there is only one Unicode and that it is 16-bits (UCS-2). I get this *all* the time. Addison === Addison P. PhillipsPrincipal Consultant Inter-Locale LLChttp://www.inter-locale.com Los Gatos, CA, USA mailto:[EMAIL PROTECTED] +1 408.210.3569 (mobile) +1 408.904.4762 (fax) === Globalization Engineering & Consulting Services On Thu, 20 Jul 2000, Michael (michka) Kaplan wrote: > Although there is some truth here the fact is that it is not really true > today that everyone equates the two. The default thought on people's minds > these days when they think of Unicode is UTF-8, it seems like. And this is > mainly due to applications of Unicode to the web, I think. > > In the meantime, Microsoft is still pretty firmly rooted in the idea that > Unicode=USC-2 (or UTF-16le on Windows 2000). UTF-8 is named UTF-8 and > considered to be a multibyte encoding. > > michka > > > - Original Message - > From: "Doug Ewell" <[EMAIL PROTECTED]> > To: "Unicode List" <[EMAIL PROTECTED]> > Sent: Thursday, July 20, 2000 10:41 PM > Subject: Re: Unicode in VFAT file system > > > > Addison Phillips <[EMAIL PROTECTED]> wrote: > > > > > Avoiding for the moment the word-parsing that Markus suggests, Unicode > > > on Microsoft platforms has always been LE (at least on Intel) and they > > > have called the encoding they use "UCS-2" (when they bothered with > > > such things: in the past they always called it "Unicode" as if it were > > > the *only* encoding). As Unicode has evolved, Microsoft products have > > > become more exact in this regard. > > > > I remember that in the early to mid '90s, before the invention (or at > > least widespread use) of UTF-8, UTF-32, and surrogates, *everybody* -- > > not just Microsoft -- used the term "Unicode" to refer to what we would > > now call UCS-2. Even the Unicode Consortium did this! And even now, > > the few of my co-workers who know about Unicode (I'm trying to spread > > the word, folks, honest) think a "Unicode text file" is UCS-2 by > > definition. I don't know what they would think of a UTF-8 file -- > > nobody but me is knowingly using them yet. In any case, this usage is > > by no means confined to Microsoft. > > > > -Doug Ewell > > Fullerton, California > > > >
Re: Unicode in VFAT file system
Ah, I did know that! :-) The place I find a UTF-8 bias most often is in people doing web content and people working with Oracle. Good to know there are others with UCS-2/UTF-16 biases! And of course its even better when we get them to accept that they are mainly different ways of expressing the same thing. michka - Original Message - From: <[EMAIL PROTECTED]> To: "Michael (michka) Kaplan" <[EMAIL PROTECTED]> Cc: "Unicode List" <[EMAIL PROTECTED]> Sent: Thursday, July 27, 2000 1:56 AM Subject: Re: Unicode in VFAT file system > That's not true. Even serious UNIX shops start with the perception that > there is only one Unicode and that it is 16-bits (UCS-2). I get this *all* > the time. > > Addison > > === > Addison P. PhillipsPrincipal Consultant > Inter-Locale LLChttp://www.inter-locale.com > Los Gatos, CA, USA mailto:[EMAIL PROTECTED] > > +1 408.210.3569 (mobile) +1 408.904.4762 (fax) > === > Globalization Engineering & Consulting Services > > On Thu, 20 Jul 2000, Michael (michka) Kaplan wrote: > > > Although there is some truth here the fact is that it is not really true > > today that everyone equates the two. The default thought on people's minds > > these days when they think of Unicode is UTF-8, it seems like. And this is > > mainly due to applications of Unicode to the web, I think. > > > > In the meantime, Microsoft is still pretty firmly rooted in the idea that > > Unicode=USC-2 (or UTF-16le on Windows 2000). UTF-8 is named UTF-8 and > > considered to be a multibyte encoding. > > > > michka > > > > > > - Original Message - > > From: "Doug Ewell" <[EMAIL PROTECTED]> > > To: "Unicode List" <[EMAIL PROTECTED]> > > Sent: Thursday, July 20, 2000 10:41 PM > > Subject: Re: Unicode in VFAT file system > > > > > > > Addison Phillips <[EMAIL PROTECTED]> wrote: > > > > > > > Avoiding for the moment the word-parsing that Markus suggests, Unicode > > > > on Microsoft platforms has always been LE (at least on Intel) and they > > > > have called the encoding they use "UCS-2" (when they bothered with > > > > such things: in the past they always called it "Unicode" as if it were > > > > the *only* encoding). As Unicode has evolved, Microsoft products have > > > > become more exact in this regard. > > > > > > I remember that in the early to mid '90s, before the invention (or at > > > least widespread use) of UTF-8, UTF-32, and surrogates, *everybody* -- > > > not just Microsoft -- used the term "Unicode" to refer to what we would > > > now call UCS-2. Even the Unicode Consortium did this! And even now, > > > the few of my co-workers who know about Unicode (I'm trying to spread > > > the word, folks, honest) think a "Unicode text file" is UCS-2 by > > > definition. I don't know what they would think of a UTF-8 file -- > > > nobody but me is knowingly using them yet. In any case, this usage is > > > by no means confined to Microsoft. > > > > > > -Doug Ewell > > > Fullerton, California > > > > > > > > >
Re: Unicode keyboard editor utility
I wish Manuel had mentioned which 3rd-party products he had in mind (I'm always interested in knowing what's out there). But, a new version of Tavultesoft Keyboard Manager (aka Keyman) is being developed, and I understand it should be available by the end of the year. The new version is supposed to do Unicode (though, obviously, not necessarily on Win9x/Me). Keyman makes it very easy to create your own keyboard layouts, and also allows you to do some fairly sophisticated things - it was originally designed to be able to handle generating presentation-form-encoded text using custom encodings of complex SE Asian scripts. So, for example, you could use it to create an input method for a large character set, such as Ethiopic. (But it doesn't yet do input method *editors*, i.e. something that handles an intermediate state of text in a separate editing mini-Window, so it's not really suited to *very large* character sets, such as CJK.) You could probably also use it to ensure that the input text is canonically ordered or even in a particular normal form. Tavultesoft's site is at http://www.tavultesoft.com - Peter --- Peter Constable Non-Roman Script Initiative, SIL International 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA Tel: +1 972 708 7485 E-mail: <[EMAIL PROTECTED]> >Anyone knows about such a utility? > >-Original Message- >From: Manuel Lopez [mailto:[EMAIL PROTECTED]] >Sent: Sunday, July 16, 2000 9:22 PM >To: [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Minor issues > > >[] > >A side comment: >I'm surprised that NT and Windows 2000, and every other Unicode OS, is >missing a >Unicode keyboard editor utility (and a utility to display keyboard mappings >to >Unicode values). There are only a couple of 3rd-party products and they're >not that >good, and this is actually a much easier program to write than word >processing (which >already exists). > >Keep up the good work, >Manuel Lopez > >
Re: Unicode in VFAT file system
Well... there was only one Unicode in those days. But the vagueness persisted after its time. This is fine in the consumer documentation, where it really doesn't matter. But in the development docs it is a real problem. Of course, I understand that software development cycles, the size of the Windows API, and other factors are also involved. And no, Microsoft isn't alone in this. But it is important to point out to Windows developers where the documentation is deficient. If we were talking about some other system, I'd probably have similar comments to make (or worse comments: at least MS went to the considerable difficulty of building Unicode support into NT from the get-go). Regards, Addison On Fri, 21 Jul 2000, Doug Ewell wrote: > Addison Phillips <[EMAIL PROTECTED]> wrote: > > > Avoiding for the moment the word-parsing that Markus suggests, Unicode > > on Microsoft platforms has always been LE (at least on Intel) and they > > have called the encoding they use "UCS-2" (when they bothered with > > such things: in the past they always called it "Unicode" as if it were > > the *only* encoding). As Unicode has evolved, Microsoft products have > > become more exact in this regard. > > I remember that in the early to mid '90s, before the invention (or at > least widespread use) of UTF-8, UTF-32, and surrogates, *everybody* -- > not just Microsoft -- used the term "Unicode" to refer to what we would > now call UCS-2. Even the Unicode Consortium did this! And even now, > the few of my co-workers who know about Unicode (I'm trying to spread > the word, folks, honest) think a "Unicode text file" is UCS-2 by > definition. I don't know what they would think of a UTF-8 file -- > nobody but me is knowingly using them yet. In any case, this usage is > by no means confined to Microsoft. > > -Doug Ewell > Fullerton, California >
Re: Making Unicode characters
>How do I make U+5973, for instance? I want to make >it so I can see it on the screen. I want to do that >without cheating by e.g. using Paint. What do you mean my "make"? Invent it? Already done. Create a font with an appropriate glyph? Go buy Fontographer, FontLab or RoboFog. Get it into your document? Well, there's lots of ways to skin that cat, one of them being to fire up you're favourite programming tool, bone up on the appropriate DDK, and write a keyboard driver. Or stay tuned for something like Keyman 5 from Tavultesoft. >Magda, if you're in programming, make it (the keyboard >utility) yourself. Why are we picking on Magda? - Peter --- Peter Constable Non-Roman Script Initiative, SIL International 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA Tel: +1 972 708 7485 E-mail: <[EMAIL PROTECTED]>
RE: Unicode keyboard editor utility
Magda Danish asked if anyone knew of a Unicode keyboard editor utility. There is a beta release of version 5.0 of Keyboard Manager that supports Unicode characters and works with Windows NT. It can be downloaded from http://www.tavultesoft.com/keyman/. Janko's Keyboard Generator is for Windows 95 and 98, and does not seem to support Unicode. http://solair.eunet.yu/~janko/engdload.htm I have recently come across 3-D Keyboard, but I have not had time to investigate it. http://www.fingertipsoft.com/3dkbd/index.html When I get time, I will add the latter 2 to my page of font and keyboard utilities at: http://www.hclrss.demon.co.uk/unicode/utilities_fonts.html Alan Wood (Documentation Writer / Web Master) Context Limited (Electronic publishers of UK and EU legal and official documents) mailto:[EMAIL PROTECTED] http://www.context.co.uk/ http://www.alanwood.net/ (Unicode, special characters, pesticide names)
Re: SQL Server and Unicode
SQL Server supports the datatypes NTEXT, NCHAR, and NVARCHAR, all of which are of type UCS-2. When such a column indexed, then the index is Unicode (I am not sure if this what you mean). SQL Server 7.0 only supports one language collation at the server level this choice affects the actual ordering of all such indexes. SQL Server 2000 supports a COLLATE keyword that allows you to specify a collation at the database or field level and thus choose a different language for such columns/indexes if you like (I discuss practical details and implications of this feature in an upcoming article in the Visual Basic Programmer's Journal, tentatively scheduled for November). In any case, you can certainly query and such field in either SQL 7.0 or in SQL 2000. Hopefully this answers your question; if not, let me know. :-) michka - Original Message - From: "pierre vaures" <[EMAIL PROTECTED]> To: "Unicode List" <[EMAIL PROTECTED]> Sent: Wednesday, July 26, 2000 1:23 AM Subject: SQL Server and Unicode > To Whom It May Concern: > > > SQL server is in the Unicode Products WebSite described as Unicode enables. > > What we would like to know is : > > a - Does SQL Server allows to set as an index a field in Unicode standard? > b - Can you make SQL query on this particular field? > > If you have any information, or ideas, thanks for your help. > > Regards, > > Pierre >
Re: Display Persian characters under Linux
Thanks for information. There is also a FarsiTeX Research Group for over 10 years based at Tehran University. But I am not sure whether they work with Unicode. regards Darya "N.R.Liwal" schrieb: I recommend that you have look at ArabicTexor write to Prof. Klaus Lagally Institut fuer Informatik Universitaet Stuttgart Breitwiesenstrasse 20-22 D-70565 Stuttgart GERMANY [EMAIL PROTECTED]he did some work on ArabicTex, he might be of help. Liwal - Original Message - From: Darya Said-Akbari To: Unicode List Sent: Tuesday, July 25, 2000 4:22 PM Subject: Display Persian characters under Linux Hi, this is my firts email to the Unicode email list. There is a lot I want to learn from you all. So even if my questions are sometimes stupid, nevertheless I like to read your answer on all issues. My goal turning my interest on Unicode is to get Persian letters on my Monitor and into a database lets say in Oracle8i. The operating system will be Linux. So, what I have done until now is to buy the Unicode Standard 3.0. But that is not enough and therefore I need your help. What steps do I have to do to get my dream real. Yes, I have several character sets on my machine but they are all european one. And honestly I am a little bit afraid to touch them, since I dont know the different between a character set and unicode. Reading the first pages of the book, makes me more confuse. There is something talken about rendering. It seems when I use the ARABIC letters I have to concern on rendering. Is there anybody who can give me a quickstart to get rid of confusing charsets, unicode, rendering etc.? I know I have to put more time on this issue and I am prepared for this. But a little success would really motivate me. best regards Darya Said-Akbari
Re: Display Persian characters under Linux
I recommend that you have look at ArabicTex or write to Prof. Klaus Lagally Institut fuer Informatik Universitaet Stuttgart Breitwiesenstrasse 20-22 D-70565 Stuttgart GERMANY [EMAIL PROTECTED] he did some work on ArabicTex, he might be of help. Liwal - Original Message - From: Darya Said-Akbari To: Unicode List Sent: Tuesday, July 25, 2000 4:22 PM Subject: Display Persian characters under Linux Hi, this is my firts email to the Unicode email list. There is a lot I want to learn from you all. So even if my questions are sometimes stupid, nevertheless I like to read your answer on all issues. My goal turning my interest on Unicode is to get Persian letters on my Monitor and into a database lets say in Oracle8i. The operating system will be Linux. So, what I have done until now is to buy the Unicode Standard 3.0. But that is not enough and therefore I need your help. What steps do I have to do to get my dream real. Yes, I have several character sets on my machine but they are all european one. And honestly I am a little bit afraid to touch them, since I dont know the different between a character set and unicode. Reading the first pages of the book, makes me more confuse. There is something talken about rendering. It seems when I use the ARABIC letters I have to concern on rendering. Is there anybody who can give me a quickstart to get rid of confusing charsets, unicode, rendering etc.? I know I have to put more time on this issue and I am prepared for this. But a little success would really motivate me. best regards Darya Said-Akbari
SQL Server and Unicode
To Whom It May Concern: SQL server is in the Unicode Products WebSite described as Unicode enables. What we would like to know is : a - Does SQL Server allows to set as an index a field in Unicode standard? b - Can you make SQL query on this particular field? If you have any information, or ideas, thanks for your help. Regards, Pierre
