Re: japanese xml

2001-09-04 Thread David Starner
On Mon, Sep 03, 2001 at 10:29:51PM -0700, Michael (michka) Kaplan wrote: This is only a problem for people who do not want to use Unicode. No! It's a problem with anyone who has to interoperate with people using non-Unicode systems or needs to use legacy data. Would you be that dismissive

Re: japanese xml

2001-09-04 Thread Michael \(michka\) Kaplan
From: David Starner [EMAIL PROTECTED] Frankly, the attitude of Forget all the stuff that you have working; just throw it all away and move to Unicode is not one that wins many converts. Backward compatibility and the ability to interface with other systems running different stuff is always

Re: japanese xml

2001-09-04 Thread David Starner
On Mon, Sep 03, 2001 at 10:59:26PM -0700, Michael (michka) Kaplan wrote: Actually, I would be (happens now with CP-1252 vs. ISO-8858-1). Where? What characters? I glanced at a local copy of the Unicode charts for them, and both were the identity function for characters in ASCII. I'm not

Re: japanese xml

2001-09-04 Thread KUSANO Takayuki
At Mon, 3 Sep 2001 22:29:51 -0700, Michael (michka) Kaplan wrote: This is only a problem for people who do not want to use Unicode. But, most people can't live without 'legacy' encodings, because there are many documents, data in 'legacy' encodings and there are stille many

Re: japanese xml

2001-09-04 Thread Michael \(michka\) Kaplan
From: KUSANO Takayuki [EMAIL PROTECTED] This is only a problem for people who do not want to use Unicode. But, most people can't live without 'legacy' encodings, because there are many documents, data in 'legacy' encodings and there are stille many applications/terminals that cannot

MSLU

2001-09-04 Thread Fazakas Lehel
Thank you to all the ideas sent me about forcing Unicode on Win95/98. I tryed out the MSLU and I found that is useful to me. The only problem is that I can't use it with VBasic 6.0 . When I try to add to References it doesn't work. And how can I get a documentation of MSLU?

RE: japanese xml

2001-09-04 Thread Marco Cimarosti
Michael (michka) Kaplan wrote: This is only a problem for people who do not want to use Unicode. Yeah, right! Look at this guy, for instance: [...] From: Michael \(michka\) Kaplan [EMAIL PROTECTED] To: David Starner [EMAIL PROTECTED], [EMAIL PROTECTED] Cc:

Re: (Typing wide characters in Windows)

2001-09-04 Thread Otto Stolz
てんどうりゅうじ wrote: Windows is a royal pain sometimes, and this is one of these times. The only thing I can suggest is [...] an Asian version of Windows, ... Anybody out there have better ideas?? Try the Global IME from http://www.microsoft.com/windows/ie/downloads/recommended/ime/default.asp.

Adding fonts to JVM

2001-09-04 Thread Sameer
Hi all Ihave an applet which contains a drop down list having all fonts present in my JVM. Now I need to add another font to this drop down. This would mean adding the font to the JVM. How can this be achieved? I have tried modifying the font.properties file but it does not seem to work.

RE: Adding fonts to JVM

2001-09-04 Thread Addison Phillips [wM]
Hi Sameer, The "font list" in your JVM comes from the operating system. The list you see is what the JVM thinks you have installed locally. To add a font to the list, you have to install the font. Best Regards, Addison Addison P. PhillipsGlobalization Architect / Manager, Globalization

Re: MSLU

2001-09-04 Thread Michael \(michka\) Kaplan
MSLU is documented in the Platform SDK. BUT you are not going to get Unicode *functionality* from MSLU, from VB or elsewhere; MSLU only gives you a wrapper layer (and it converts after that), so the work you would do to make it callable from VB would not actually be beneficial? MichKa Michael

Dead code in samples

2001-09-04 Thread Igor Bukanov
It seems that a sample UTF32 to UTF8 conversion in http://www.unicode.org/Public/PROGRAMS/CVTUTF/ConvertUTF.c contains dead code. In particular, the ConvertUTF8toUTF32 method has: if (ch = UNI_MAX_UTF32) { *target++ = ch; } else if (ch

RE: Dead code in samples

2001-09-04 Thread Marco Cimarosti
Igor Bukanov wrote: It seems that a sample UTF32 to UTF8 conversion in http://www.unicode.org/Public/PROGRAMS/CVTUTF/ConvertUTF.c contains dead code. In particular, the ConvertUTF8toUTF32 method has: if (ch = UNI_MAX_UTF32) { *target++ = ch;

Re: japanese xml

2001-09-04 Thread John Cowan
Marco Cimarosti scripsit: [...] Definition: A character is an atomic unit of text as specified by ISO/IEC 10646 [ISO/IEC 10646] [...] I should not try to interpret XML specs. 'Anyway, my understanding is that the XML legislators are simply saying that they adopt Unicode definition of

UTF-8 on NT

2001-09-04 Thread Changjian_Sun
Not like in unix, we can set French UTF-8 locale by calling setlocale(LC_ALL, fr_CA.UTF-8), On NT, I don't know how to set French UTF-8 locale, setlocale(LC_ALL, French_Canada.1252) seems not for UTF-8 My questions: 1. Is UTF-8 supported on NT ? 2. If yes, how to use setlocale() to set it up

Re: UTF-8 on NT

2001-09-04 Thread Michael \(michka\) Kaplan
This is not an NT issue so much as a Visual C++ CRT issue (the setloale function is implemented there, for what you are probably using). At present, there is no support for this (take a look at the code if you need to know why, it makes all kinds of assumptions like one byte per character that

RE: UTF-8 on NT

2001-09-04 Thread Vaintroub, Wladislav
I'm afraid ,that thereno way to set UTF-8 locale on Windows via setlocale. Even if you try to do this with setlocale("French_Canada.65001") it won't work correctly. It's a pitty , because the porting of Unix programms,relying on UTF-8 locale becomes very challenging task on Windows.

RE: UTF-8 on NT

2001-09-04 Thread Changjian_Sun
Do you think that UTF-8 is the wrong way for internationalization of cross-platform software ? Our application supports solaris, hpux, aix and NT. To internationalize it, we are thinking of UTF-8 (setlocale(), strcoll() for sorting, mbstowcs() for length...) so that we don't have to add wide

RE: UTF-8 on NT

2001-09-04 Thread Yves Arrouye
I'm also thinking of 3rd party UTF-8 support such as libutf8, IBM ICU. They seem no good supports on NT, what do you think ?We are usingICU for all our Unicode needs,on NT, Windows 2000, and Unix, and itworks perfectlywell on all of these. YA

RE: UTF-8 on NT

2001-09-04 Thread Timothy Greenwood
I'm afraid ,that there no way to set UTF-8 locale on Windows via setlocale. Even if you try to do this with setlocale(French_Canada.65001) it won't work correctly. It's a pitty , because the porting of Unix programms,relying on UTF-8 locale becomes very challenging task on Windows. What

Re: UTF-8 on NT

2001-09-04 Thread Markus Scherer
No. On Windows NT/2000/XP/CE, everything is UTF-16 Unicode, for all locales. Locales and codepages are separate, as they should be. You should compile your programs with UNICODE and _UNICODE defined to use the native Unicode kernel functions. UTF-8 is not possible - as far as I know - as a

Re: TOP/BOTTOM HORIZONTAL BOX LINE: new characters?

2001-09-04 Thread Eric Muller
Michael (michka) Kaplan wrote: Is there an actual case to be made for the usefulness of these suggested characters in any known implementation? Yes. A number of fonts contain either the four sides (e.g. Cheq in our library), or the four sides and the four corners (e.g. the border fonts in

RE: UTF-8 on NT

2001-09-04 Thread Carl W. Brown
Changjian Sun, If you have code that is currently setlocale based then there is an easy conversion to Unicode. With xIUAhttp://www.xnetinc.com/xiua/ you have a straight migration path to use the wonderful power of ICU. You start by replacing your current i18n functions such

Re: TOP/BOTTOM HORIZONTAL BOX LINE: new characters?

2001-09-04 Thread James Kass
Eric Muller wrote: I am wondering whether to propose two new characters. The goal is to have a consistent set of characters to represent the four sides and four corners of a box. I looked at the Box Drawing block, but there are a few problems with those: - there is no distinction of

Re: TOP/BOTTOM HORIZONTAL BOX LINE: new characters?

2001-09-04 Thread Eric Muller
James Kass wrote: Should there be a distinction? If so, why? Because typographic borders often have different glyphs for each side. They could either align differently with other glyphs, or show different (typically symmetric) ink. I suppose you could argue that a layout engine should

Re: TOP/BOTTOM HORIZONTAL BOX LINE: new characters?

2001-09-04 Thread James Kass
Eric Muller wrote: Should there be a distinction? If so, why? Because typographic borders often have different glyphs for each side. They could either align differently with other glyphs, or show different (typically symmetric) ink. I suppose you could argue that a layout engine