From: "Richard Cook" <[EMAIL PROTECTED]>
> This must be the Beijing Zhong Yi Electronics font ... I heard that
> Microsoft was licensing it, but didn't imagine they'd release it so soon
...
The font vendor is listed as BDFX, and the copyright is for the Founder
Corporation. Further respondant sa
From: "John H. Jenkins" <[EMAIL PROTECTED]>
> >Has the UNIHAN.TXT file been updated to include radical-stroke data
> >for Plane Two characters?
> Yes. Ever since Unicode 3.1 was released. (We still don't have an
> Extension B font, however.)
There is one in Office XP's CHS and CHP language pa
From: "てんどうりゅうじ" <[EMAIL PROTECTED]>
> >> Perhaps he (縺ヲ繧薙←縺・ｊ繧・≧縺・ was lamenting the character's
>absence
> >> in the Han Radical Index section under radical # 85.
> Yes. It belongs there.
Its so sad that you do not have a UTF-8 compatible e-mail client. :-(
> Come on. What ワープロばか (which pro
From: "Michael Everson" <[EMAIL PROTECTED]>
> At 09:47 -0700 2001-07-08, Michael \(michka\) Kaplan wrote:
>
> >Perhaps a rule needs to be imposed about the amount of sake that should
be
> >consumed before submitting a character proposal?
>
> I've n
From: "James Kass" <[EMAIL PROTECTED]>
> Perhaps he (てんどうりゅうじ) was lamenting the character's absence
> in the Han Radical Index section under radical # 85.
>
> If all the characters made from the water radical were listed
> under that radical in the Han Radical Index (and so forth),
> where would
From: "てんどうりゅうじ" <[EMAIL PROTECTED]>
> I mean. You take the radical of 水 (water) and add 7 strokes a certain way
to get 酒 (sake).
> It was not there, alas.
Actually, you are mistaken; U+9152 does indeed represent the character you
wanted, else this (UTF-8 encoded!) message would not be able to
From: "Kenneth Whistler" <[EMAIL PROTECTED]>
> > You can just call me a consciencious objector to having anyone who
> > subscribes to "Vinyar Tengwar" considering themselves to be among the
> > Númenoreans (a.k.a. the Dúnedain), who alone of all the races of Men
knew
> > Elvish tongues. :-)
>
> A
From: "Kenneth Whistler" <[EMAIL PROTECTED]>
> I've been lurking on this discussion, but have to chime in here.
I do appreciate it, for what its worth. The chime was very much in tune.
While fully recognizing the importance of Middle Earth to some people it is
difficult for me to get past the f
From: "Michael Everson" <[EMAIL PROTECTED]>
> >>The editorial response to comments from national groups, in the
> >>public archive of ISO 10646 stuff that you linked to at the start
> >>of this message, included a complaint about Deseret from the German
> >>Standards body, in that it was inapprop
From: "John Cowan" <[EMAIL PROTECTED]>
> Just so, which means that the energy spent on invented scripts is nowise
> taken away from the energy that could be spent on obscure-but-real
scripts.
> Would that it were otherwise.
No one is arguing the FACTUAL basis for the above, but it is quite
reaso
From: <[EMAIL PROTECTED]>
> What's "bad" is that work seems to get done on fictional scripts while
there
> are still millions of real people (some of whom even have access to
> computers) who can't express texts of their natively-used languages with
> Unicode because we don't have their scripts e
Well, I cannot speak for PowerBuilder (my knowledge of it is very out of
date), but for both Netscape and MS SQL Server you may or may not be able to
support Indic scripts -- the deciding factor will be based on what version
of each product you are using.
Beyond that, I do not think that any one
> Hee hee - unless you're packing a guide to anime, you'll never find
> 'em anyway. らんま is Ranma, as in Ranma Saotome, and あかね is Akane, as in
> Akane Tendo, the two main stars of Rumiko Takahashi's bizarre (if
> monothematic) sex comedy "Ranma 1/2".
Seeing this wonderful use of Unicode text in
From: "John Cowan" <[EMAIL PROTECTED]>
> > As for whether your script would be encoded, where it ends up vis-a-vis
the
> > "potential" roadmap is more a side effect of who you know than anything
else.
>
> Smiley or not, someone might actually believe that, and it
> isn't true. Michael Everson is
From: "John H. Jenkins" <[EMAIL PROTECTED]>
> FWIW, there is a small but non-zero Shavian user community, and a
> number of fonts are available, some of them very pretty.
Of this I have no doubt -- but this was true of Klingon, also.
I was expressing doubt that the majority of the community ar
From: "Richard Cook" <[EMAIL PROTECTED]>
> now, I know of other phonemic alphabets for English ... e.g., I think
> Ben Franklin invented one, ... and I have one of my own. Are any of
> these slated for encoding too?
Fictional scripts have been, are, and will likely continue to be a constant
sour
From: "Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]>
> It's a pity that UTF-16 doesn't encode characters up to U+F, such
> that code points corresponding to lone surrogates can be encoded as
> pairs of surrogates.
Unfortunately, we would then be stuck with what happens when two such
surroga
From: <[EMAIL PROTECTED]>
> I'm never ashamed of perfectly good code I've written to fulfill a
humorous
> requirement. I'm only ashamed of badly written code, or code that
implements
> a bad idea that someone else thinks is a good idea.
The latter is kind of the worry I had -- a long time ago I
From: <[EMAIL PROTECTED]>
> Oh yeah, well, I can be more tongue-in-cheek than all of you. I've
already
> implemented it.
Doug, this is one of those things one should be ashamed of, like believing
in the April Fool's Day message about "self serve encodings" enough to have
put together a proposal
From: "Jianping Yang" <[EMAIL PROTECTED]>
> "Carl W. Brown" wrote:
> > If there are no surrogates in the database, is there any reason that I
can
> > not change the database from UTF8 to AL32UTF8?
>
> You can change the database from UTF8 to AL32UTF8 in this case. Also you
can
> use Oracle databa
From: <[EMAIL PROTECTED]>
> Waiting until characters were assigned
> outside the BMP to start working on the UCS-2 problem is like waiting
until
> 2000-01-01 to start working on the Y2K problem.
Its actually a bit worse than this -- its coming up with a solution to Y2K
problems that requires oth
From: "$B$F$s$I$&$j$e$&$8(B" <[EMAIL PROTECTED]>
> 2) GET THE FREAKING BOOK AND LOOK AT IT and don't so anything stupid like
confuse "8" with "B".
No one would ever do this, really. The real world does foolish things like
use standard keyboards that do not lie to us with what we type, on top of
From: <[EMAIL PROTECTED]>
> On 06/15/2001 06:29:51 PM "Michael \(michka\) Kaplan" wrote:
> >Why be more specific then there are a lot of people who think they might
> >possibly have made TOO MUCH normative and do not want to make things
> >unchangeable th
From: <[EMAIL PROTECTED]>
> Can anyone give me a specific example of why Line Breaking or East Asian
> Width properties aren't normative?
Why be more specific then there are a lot of people who think they might
possibly have made TOO MUCH normative and do not want to make things
unchangeable tha
From: "Youtie Effaight" <[EMAIL PROTECTED]>
> Well, Mister Constable. What's new about that? Looks to me
> like e-Leven Digit Grrl just forgot to turn off her microphone
> again... We're witnessing the spacey under-mumble of a quickly
> crumbling mind. Maybe we'll get lucky and she'll burn up o
From: <[EMAIL PROTECTED]>
> Out of curiousity, is there documentation on XCCS available anywhere?
Check out google.com: it will get about 120+ hits on the words "XCCS
standard" and several of them seem vaguely relevant. :-)
MichKa
Michael Kaplan
Trigeminal Software, Inc.
http://www.trigeminal.
From: "Mark Davis" <[EMAIL PROTECTED]>
> UTF-8 was defined before UTF-16. At the time it was first defined, there
> were no surrogates, so there was no special handling of the D800..DFFF
code
> points.
In other words, Oracle has an alternate solution here for 9i -- they can
simply explain that t
From: "Jianping Yang" <[EMAIL PROTECTED]>
> Oracle is promoting and following the standard. Same as most other
database
> vendors, our database does not fully support supplementary character in
Oracle
> 8i and Oracle 7. But as we see the need to support it, we extend this
support
> in Oracle 9i.
From: "Jianping Yang" <[EMAIL PROTECTED]>
> > If UTF-8S were to by some miracle be accepted by
> > the UTC, implementers will be put out and offended
> > for most of the next decade.
> >
>
> If it is, that is rule of law from UTC.
Very true.
And if they vote against it, will you do the right
From: "Jianping Yang" <[EMAIL PROTECTED]>
> Is this the language that should be used in a professional way? I wonder
> how could this happen to the Unicode mail list!
So many linguists afoot, and we will get bogged down in my attempts to
provide a little spice to the subject?
The difference, of
From: "Carl W. Brown" <[EMAIL PROTECTED]>
> I am proposing that we fix UTF-16.
Are you formally proposing this? For the next UTC meeting?
michka
(whoops, sent too soon!)
From: "Carl W. Brown" <[EMAIL PROTECTED]>
> I am proposing that we fix UTF-16.
Are you formally proposing this? For the next UTC meeting? Without an actual
customer that is wanting it for an implementation I am pretty sure this will
be voted down pretty loudly.
michka
From: "Rick McGowan" <[EMAIL PROTECTED]>
> > ... asking for a lavicious license to be lecherously lazy
>
> Parse error at "lavicious". No such word appears in any English
> dictionary I own, not even the OED.
Sorry, that was to be lascivious.
Glad someone is still parsing in this thread.
m
From: "Carl W. Brown" <[EMAIL PROTECTED]>
> I first I thought the same thing but I have changed my mind. There are
> problems but the problems are with UTF-16 not UTF-8. I don't think that I
> am the only one who thinks that UTF-8s will create more problems that it
> fixes.
>
> Worse yet they w
From: "Carl W. Brown" <[EMAIL PROTECTED]>
> I think that UTF-16x would be a better approach than UTF-8s. I am sure
that
> I have missed some issues feel free to comment. In any case UTF-16s would
> naturally be in Unicode code point order. It would be easy to transform
to
> UCS-2 for applicati
From: "$B$F$s$I$&$j$e$&$8(B" <[EMAIL PROTECTED]>
> A search engine regards the words "stone" and "STONE" as identical.
> So why isn't $B$$$7(B treated the same as $B%$%7(B? The difference can be
> quite marked, such as $B%l%$%W(B versus $B$l$$$W(B or such.
Well, there is nothing to stop
We don't have Paul Clayton's e-mail address, but I assume you can forward
on, Magda?
SQL Server, ASP, and VB are all able to support UTF-16, which is a 16-bit
per code point encoding form. The term "16 bit character set" is a bit
unclear in its meaning, what exactly Paul is looking for here would
From: "Mark Davis" <[EMAIL PROTECTED]>
> From: "Marco Cimarosti" <[EMAIL PROTECTED]>
> > But how should this 6-byte sequence be interpreted by a standard UTF-8
> > decoder? Does it become one or two code points?
> It is either one code point (lenient parser) or an error (strict parser).
It
> is
From: "Misha Wolf" <[EMAIL PROTECTED]>
> Let's be careful with the word "legal". The strange (per-)version of
> UTF-8 which re-encodes UTF-16 is legal input as far as The Unicode
> Standard is concerned. It is, however, totally illegal as far as the
> IETF, the Internet, the W3C, the WWW, XML,
From: <[EMAIL PROTECTED]>
> On 06/04/2001 02:10:35 AM Doug Ewell wrote:
> >While we are at it, here's another argument against the existence of both
> >UTF-8 and this new UTF-8s. Recently there was a discussion about the use
> of
> >the U+FEFF signature in UTF-8 files, with a fair number of Unic
From: "Mark Davis" <[EMAIL PROTECTED]>
> 2. Auto-detection does not particularly favor one side or the other.
>
> UTF-8 and UTF-8s are strictly non-overlapping. If you ever encounter a
> supplementary character expressed with two 3-byte values, you know you do
> not have pure UTF-8. If you ever e
From: "Marco Cimarosti" <[EMAIL PROTECTED]>
> No, please, let's not make waters more muddied than they already are.
Let's
> keep on calling Oracle's proposal "UTF-8S", as there is no point in
finding
> a cuter name for it.
Fair enough.
> Wrong point! Perhaps it will not hurt applications which
Simon,
Would you care to answer (officially) why exactly Oracle needs for anything
to be done here? Per the spec, it is not illegal for a process to interpret
5/6-byte supplementary characters; it is only illegal to emit them. It seems
that Oracle and everyone else is well covered with the existi
Simon,
Would you care to answer (officially) why exactly Oracle needs for anything
to be done here? Per the spec, it is not illegal for a process to interpret
5/6-byte supplementary characters; it is only illegal to emit them. It seems
that Oracle and everyone else is well covered with the existi
From: "Jianping Yang" <[EMAIL PROTECTED]>
> As a matter of fact, the surrogate or supplementary
> character was not defined in the past, so we could
> live without Premise B in the past. But now the
> supplementary character is defined and will soon be
> supported, we have to bother with it.
Poo
It was not shot down entirely... in baseball terms, the umpire said "Foul
tip, strike two" (strike one was the last time). :-)
michka
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 25, 2001 12:49 PM
Subject: RE: ISO vs Unicode UTF-8 (was RE: UTF-
From: "11 digit boy" <[EMAIL PROTECTED]>
>>I have worked with many terminal emulator systems that use
>>mono-spaced fonts. The first place you start having problems
>>is with script fonts like Arabic. With Indic languages you often
>>have to reorder characters before rendering
> Um. How about
From: "G. Adam Stanislav" <[EMAIL PROTECTED]>
> At 13:11 22-05-2001 -0700, Carl W. Brown wrote:
> >There is no easy solution.
>
> Yes, there is, though it is probably beyond the scope of this list.
>
> Nevertheless, there is a very simple solution. It needs to be done
> on the OS level: Create met
If you are doing this in Access 2000, then the choice has been taken away
from you: your only choice is Unicode (UCS-2/UTF-16 to be precise).
There is an article I wrote back in April 2000 on international apps in
Access 2000 (followed up by a June 2000 article on localized application in
Access
From: "Graham Asher" <[EMAIL PROTECTED]>
> But I guess this is obvious. I just wanted to chime in with the view that
a
> single Unicode Font would be useful, and a whole lot better than some
> people suggest.
>
> As an implementer of rasterizers and text layout systems I can also state
> that th
From: <[EMAIL PROTECTED]>
> (JDK 1.4 will only add
> support for Unicode 3.0, not 3.1, although presumably it will add the
> infrastructure for surrogate pairs which will allow your question to get
> answered meaningfully!)
Actually, no proper support for surrogate pairs means no support for
*UN
From: "11 digit boy" <[EMAIL PROTECTED]>
> And look me in the eye and tell me it is not a great trick for Kanji. I
mean, how many times are you going to keep making that water radical?
Its not all that great of a trick as far as I am concerned, but I am glad
you like it.
The known world is going
> From: <[EMAIL PROTECTED]>
>
> > If you want to specify a search option of "ignore diacritics", would
there
> > be any reason not to do simply the following>
> >
> > - normalise both data and search string
> > - delete / ignore all characters with general category Mn
>
>
> Microsoft in its FoldS
From: "11 digit boy" <[EMAIL PROTECTED]>
> Why does Unicode only have space for 1114112 glyphs?
Unicode only defines characters, not glyphs.
> That is 1114112, I think.
Something like that. It looks nicer in hex.
> You ever notice how characters in different writing systems seem to be
made out
From: <[EMAIL PROTECTED]>
> If you want to specify a search option of "ignore diacritics", would there
> be any reason not to do simply the following>
>
> - normalise both data and search string
> - delete / ignore all characters with general category Mn
Microsoft in its FoldString implementat
IE does not have specific limitations, per se, it mainly matters if you do
not choose a font explicitly and the font that is being used for the Arabic
subrange supports the character or not.
If the font does not support the character, then you will see a box there
instead; is that what you are se
From: "Edward Cherlin" <[EMAIL PROTECTED]>
"A text file with a BOM is, if not rich text, at least above the poverty
line."
(modified from Ed's prior msg -- this one is a keeper!)
michka
michka
the only book on internationalization in VB at
http://www.i18nWithVB.com/
- Original Message -
From: "Edward Cherlin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 18, 2001 1:08 PM
Subject: Re: UTF-8 signature in web and email
> At 10:58 PM -0400 5/17/01, [EMAIL
From: <[EMAIL PROTECTED]>
> But do any of them encode using code units larger than 8 bits? Certainly
if
> something like GB2312 were encoded in a flat (linear?) encoding that never
> used code-unit sequences, the code units would have to be larger than 9
> bits. But I've only ever heard of them b
Well, most of the various CJK encodings clearly would have a lot more than 9
bits to them. Kind of required for any system dealing with thousands of
characters.
MichKa
Michael Kaplan
Trigeminal Software, Inc.
http://www.trigeminal.com/
- Original Message -
From: <[EMAIL PROTECTED]>
To:
It would be most likely that "Dr. International" ([EMAIL PROTECTED]) sent
the mail from Microsoft did so from his/her Outlook machine (probably
Outlook 2002, I do not think Outlook 2000 ever did this). Perhaps someone
could follow up with the Outlook folks on their decision to include a BOM at
the
From: "Roozbeh Pournader" <[EMAIL PROTECTED]>
> > I would heartily recommend that you and the council (and everyone
there!)
> > work to solve the problem that is blocking foreign software companies
from
> > doing business in Iran: the international copyright issue.
>
> I highly agree with you. I
From: "Roozbeh Pournader" <[EMAIL PROTECTED]>
> I really hope that all the problems of Microsoft Persian keyboard gets
> fixed in the shipping version of XP.
Well, good luck on this one. With Beta 2 out, its really unlikely that you
will see a change at this point in Windows, if it has not alrea
From: "Charlie Jolly" <[EMAIL PROTECTED]>
> The PinYin IME with Windows 2000 allows
> you to input traditional caharacters.
And of course, this suggests the real answer here if you want full
multilingual support and you are on a platform that does not support this
(such as Windows ME) -- upgrade
This is probably better directed to Microsoft then to the Unicode List
(since its really not a Unicode issue but it is obviously a Microsoft one!)
but there are plenty of MS people who can take the ball and run with it.
For fonts, neither Times New Roman nor Tahoma is all that stellar for
Persian
From: "David J. Perry" <[EMAIL PROTECTED]>
> I've tried several methods of inputting the
> characters but the result is always the same.
> Does anybody know how to handle this?
I believe Word is going with the font choices you will find in the style
dialog for the given styles for "Asian langua
From: "Edward Cherlin" <[EMAIL PROTECTED]>
> OK, I tried my own advice, and this is the macro code I got back:
>
> Selection.TypeText Text:=ChrW(8204)
>
> I don't claim to understand this code entirely, but it does seem to
> work for Word 2000 under Windows 2000. That is, setting the cursor
> bet
Code2001 is one font, and if you have the Chinese version of Office XP (or
any of the Chinese langpacks) there is a surrogate IME and font (extension
B) available.
MichKa
Michael Kaplan
Trigeminal Software, Inc.
http://www.trigeminal.com/
- Original Message -
From: "Ayers, Mike" <[EMAI
From: "John H. Jenkins" <[EMAIL PROTECTED]>
> It really isn't possible to
> convert between simplified and traditional characters without doing a
> lexical analysis.
Word 2000/2002 both have a conversion utility that does the lexical analysis
that John refers to here. Others will have to speak t
From: "David Starner" <[EMAIL PROTECTED]>
http://msdn.microsoft.com/workshop/Author/dhtml/reference/charsets/charset4.
asp
> It apparently doesn't let you link directly to a page. That link come
> up "Page Not Found", but when I searched for it, I got right to that
> page.
I think it was the fa
From: "David Starner" <[EMAIL PROTECTED]>
> What does "real use" mean? The set of usable character sets is
> unbounded and hence the set of sets people use is very varied.
> My guess is to look at what the main webbrowser support.
The following link is useful for the ones IE recognizes:
http://
From: "William Overington" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, April 28, 2001 7:44 AM
Subject: Re: Tags and the Private Use Area
> The quote is an excerpt from a sentence.
Well, you did manage to go on for quite a bit. Since you were able to pick
From: "William Overington" <[EMAIL PROTECTED]>
> I have updated my suggestion. Here is the latest version for discussion.
Lets consider the fact that what you are looking for is summarized at the
end of your message: "I hope to gain fairly widespread agreement within the
unicode user community.
From: "Marco Cimarosti" <[EMAIL PROTECTED]>
> Probably, plane-14 tags should never have been there. But, once the
chicken
> is dead, the only thing left to do is having chicken for dinner... So why
> not using those tags for more services, provided that there is no disturb
to
> (the majority of) a
UTF-8 is what you need to use for the Session.CodePage on the ASP side, and
a Unicode text field (NTEXT, NCHAR, NVARCHAR) would have to be used on the
MS SQL Server side. If you do this, then you should be able to get what you
want.
What is the specific reason that you would not want to use UTF-8
> How on earth can 'ideographs' be synthesized from consonants and
> vowels? Moreover, when I wrote that 'CJK don't always go together', I
> wasn't talking about Chinese characters(ideographs) at all. I was talking
> about Korean Hangul only (I think it was pretty clear in the part of
> my messa
From: "Jungshik Shin" <[EMAIL PROTECTED]>
> > As long as specific markets remain resistant to the idea of this work
being
> > done, this is no mere myth -- it is a reality.
>
> As a general statement, I might agree to the above. However, I'm a bit
> confused as to what you're specifically talki
From: "Jungshik Shin" <[EMAIL PROTECTED]>
> Well, CJK don't always go together in information processing
> and that's one of myths to be dispelled in I18N community.
As long as specific markets remain resistant to the idea of this work being
done, this is no mere myth -- it is a reality.
michk
From: <[EMAIL PROTECTED]>
> Win95 could perhaps be looked at as a revision of Win3.x that provides
> partial support for Unicode.
I shudder at this characterization, truly. :-)
MichKa
Michael Kaplan
Trigeminal Software, Inc.
http://www.trigeminal.com/
From: "Marco Cimarosti" <[EMAIL PROTECTED]>
> Well, I am not saying that it would be easy, or that it would be worth
> doing, but would it really take *millions* of dollars for implementing
> Unicode on DOS or Windows 3.1?
With Windows CE supporting Unicode, I think it would be cheaper to get *i
From: "David Starner" <[EMAIL PROTECTED]>
> Actually, CP1252 seems
> to cover it pretty well, but it isn't covered by ASCII.
Well, one good thing about the MS code pages (for all the heat they get here
and elsewhere!) is the fact that they are very market oriented and designed
to handle whatever
< changing the title to appropriately reflect Roozbeh's thread drift :-) >
From: "Roozbeh Pournader" <[EMAIL PROTECTED]>
> > 4) Does it mean that there are no deviations between the Unicode bidi
> > algorithm and the one MS implements?
>
> BTW, has anyone listed the differences? It will be hel
From: "Andrew Cunningham" <[EMAIL PROTECTED]>
> true, personally i'd rather seem Microsft complete their unicode support
> first before doing anything with other character sets ... quite a few
years
> off full support for unicode 3.0 and 3.1
Well, I guess this is one of those huge "maybe" type q
From: "Tex Texin" <[EMAIL PROTECTED]>
To: "Michael (michka) Kaplan" <[EMAIL PROTECTED]>
> Isn't this covered by the second benefit on the page?
> Reduced development costs, etc
I guess with real-world examples it seems that its a bit more expli
From: "Tex Texin" <[EMAIL PROTECTED]>
> The fact that a product supports Unicode and does not support another
> code
> page used in some region, does not mean that the vendor
> supports that region, nor does it mean if they decide to support the
> region that it would be only with Unicode...
It
From: "Tex Texin" <[EMAIL PROTECTED]>
> If I had some examples from IBM, Sun, HP, Unisys, etc. then
> the benefit would not read like Microsoft is all that matters.
Since there are locales that do not have specific code pages recognized by
other vendors, I think you already have the proof you ar
From: "John Cowan" <[EMAIL PROTECTED]>
> Oh sure. The point is that ISCII does exist, but Microsoft does not
> support it: therefore, if you are going to do Indic languages,
> you must have Unicode (for Microsoft environments, anyway).
Actually, this is not really true... Windows 2000 and XP bo
From: "Tex Texin" <[EMAIL PROTECTED]>
> Can you point me to a reference for Microsoft's strategy, that you
> mention?
> It would be useful to anyone promoting Unicode within an organization.
Just look at the new languages they added --- not a CP_ACP among them! I
overheard the guy who did the ta
Ah, well the point in this case is that going forward, Microsoft has made a
specific decision to make sure that new languages do not use the "backwards
compatibility" mechanism of default system code pages. This does indicate
that Unicode is no longer just a feature in an application, it is pretty
From: "F. Avery Bishop" <[EMAIL PROTECTED]>
> This is *mostly* correct. None of the Indic code pages are supported as
> system code pages (aka ANSI code pages), and the 'A' versions of the
> Win32 API use the system code page to do the automatic conversion as
> mentioned above. Hence the lack of
From: <[EMAIL PROTECTED]>
> Note also that the wParam contains a Unicode character expressed in
UTF-32.
> The documentation doesn't make this clear.
"doesn't make this clear" being a euphamism for "doesn't say it at all",
right? Or more accurately, blatantly contradicts? From MSDN:
"If wParam i
From: "Lukas Pietsch" <[EMAIL PROTECTED]>
> Questions:
> (a) Is the new richedit control, and/or the new Wordpad version, available
> for download somewhere?
AFAIK, it is only currently available from Office XP. Perhaps this will
change at some point? I would hope for a redist pack so that one c
From: "Marco Cimarosti" <[EMAIL PROTECTED]>
> Yeah. Pity that the local code page is the default everywhere, and to use
> Unicode in the GUI one has to dig deep in options, registry, manuals, etc.
Well, I would not go *that* far in theory just defining _UNICODE is all
you need. How far an ap
From: "Marco Cimarosti" <[EMAIL PROTECTED]>
> This is, e.g., the way Windows NT works: Unicode is used to handle text in
> the OS core, but it is mapped to/from "code pages" as soon as it has to
> become visible to the user.
Well, not exactly though. NT works best when you use Unicode everywhere
Like Doug, I am a little curious as to the decision on where the symbol
would go... would you really want it in the presentation forms that are
merely for backwards compatibility? I think there are two options for
currency symbols:
1) In the curreny Symbols block if there is even the remotest cha
Robert,
More and more people are of the opinion with each message that if they do
not remove you from the Unicode List that there is in fact something wrong.
You need to stop this sort of nonsense. NEVER has the UTC refused to look at
a proposal, but do you think that somehow procedure is neglec
Like Doug, I am a little curious as to the decision on where the symbol
would go... would you really want it in the presentation forms that are
merely for backwards compatibility? I think there are two options for
currency symbols:
1) In the curreny Symbols block if there is even the remotest cha
From: "James Kass" <[EMAIL PROTECTED]>
> if there is a need for a keyboard method, it should be possible
> to create one.
Most assuredly... but I am hesitant to consider the 16-bit world to be
"gone" in practical terms until such methods are not only possible, but also
widespread as well.
We are
From: "James Kass" <[EMAIL PROTECTED]>
> As far as keyboards/IME, if anyone has a notion of what a Deseret
> or Gothic keyboard should look like (and a need for one), please
> let me know.
Um, the need for one is a way to actually input data? How else would a
typical user be able to type such da
From: <[EMAIL PROTECTED]>
> The historic notion
> of Unicode as a uniformly 16-bit encoding has been in principle obsolete
> for a while, but now it is also obsolete in practical terms.
Actually, I think *that* statement is a bit premature, still. It is not
obsolete in pratical terms until there
301 - 400 of 715 matches
Mail list logo
