Peter_Constable at sil dot org wrote:
A couple of corrections. First, if an app supports only WM_CHAR and
not also WM_UNICHAR, that does not imply that it uses a legacy
encoding. If running on NT/2K/XP and registered as a wide (Unicode)
app, the WM_CHAR messages will supply UTF-16 code
-BEGIN PGP SIGNED MESSAGE-
Michael (michka) Kaplan wrote:
Not sure how this could be generally possible to restrict, since
WinNT/2K/XP/.Net all will transparently map CF_TEXT an CF_UNICODETEXT so
that if one if put on the clipboard and the other is asked for, you will get
it.
Peter_Constable at sil dot org wrote:
Something that wouldn't be difficult would be an item that copied data
to the clipboard, and then displayed character info based on the
clipboard content.
Hmm, an interesting thought. I would be willing to write a mini-tool
like this, if enough people
On 08/28/2002 05:38:05 PM Doug Ewell wrote:
Edit controls (edit boxes, text widgets) in Windows already come
equipped with a right-click menu...
It's not hard to imagine that menu being extended with a Character
Info or What's This Glyph? item...
Of course, I have no idea if such a thing will
Kenneth Whistler wrote the following at 2:01 PM on Mon, Aug 26, 2002:
And an approach which strikes me as a much more useful and extensible
way to deal with this would be the concept of a What's This?
text accessory. Essentially a small tool that a user could select
a piece of text with (think
Dean Snyder dean dot snyder at jhu dot edu wrote:
Good idea - the big attraction being extensibility. But a detraction
is that it would typically mean multiple, or at least explicit,
deployment at the application level on any given platform. (I'm
presuming such a system service would present
Doug Ewell wrote the following at 8:38 AM on Wed, Aug 28, 2002:
But the advantage would be the same as what Dean
envisions for a font-based solution -- applications would get the
support for free, instead of having to re-implement it in multiple,
slightly different ways.
I don't believe so.
[Resend of a response which got eaten by the Unicode email
during the system maintenance last week. Carl already responded
to me on this, but others may not have seen what he was
responding to. --Ken]
Proposed unknown and missing character representation. This would be an
alternate to method
William,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of William Overington
Sent: Friday, August 23, 2002 12:55 AM
To: James Kass; Carl W. Brown; Unicode List
Cc: [EMAIL PROTECTED]
Subject: Re: Revised proposal for Missing character glyph
Kenneth Whistler scripsit:
Things will be better-behaved when applications finally get past the
related but worse problem of screwing up the character encodings --
which results in the more typical misdisplay: lots of recognizable
glyphs, but randomly arranged into nonsensical junk. (Ah,
Of Kenneth Whistler
Sent: Monday, August 26, 2002 2:01 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Revised proposal for Missing character glyph
[Resend of a response which got eaten by the Unicode email
during the system maintenance last week. Carl already responded
to me
At 09:49 PM 8/26/2002 -0400, John Cowan wrote:
Nowadays, experts can detect mismatched character sets from the
nature of the byte barf that appears on their screen.
And super-experts can read languages in byte barf as it is not random!
Barry Caplan
http://www.i18n.com
-BEGIN PGP SIGNED MESSAGE-
Carl W. Brown wrote:
Proposed unknown and missing character representation. This would be an
alternate to method currently described in 5.3.
The missing or unknown character would be represented as a series of
vertical hex digit pairs for each byte of
PROTECTED]
Subject: Re: Revised proposal for Missing character glyph
Proposed unknown and missing character representation. This would be an
alternate to method currently described in 5.3.
The missing or unknown character would be represented as a series of
vertical hex digit pairs for each
14 matches
Mail list logo
