Re: A Real puzzler

["Patricia M. Godfrey" priscamg@xxxxxxxx]

Harry Binswanger wrote:
has been that sensation is 246 "impoverished" vis-a-vis our actual

It looks right in my Eudora, too.
It does NOT look right in Tbird. If that were real Windows
native CP 1251, it would have real curly quotes. As I keep
my e-mail to plain text (to avoid nasties lurking in HTML),
I cannot do it here. If it were expanded mode Xy, it would
look like this:
that sensation is ≪146≫impoverished≪247≫≪/pre>
I'm not following all this, but to paste I use not clip.exe but U2 clipw.
U2 Clipw CALLS clip.exe. Look at the code, the relevant
snippet of which I paste here in pseudocode:
\CLIP.EXE  Q2 >
My long quotation from Robert was not the one I was looking
for. That was from his post of 20 Nov 2006, as follows:
≫
If I type "This is a Cedilla Ç" in XyWrite, then Copy it
with CLIP, I get "This is a Cedilla Ç" when I Paste that in
Microsoft Word. XyW command line is empty, so *CodePage
conversion* occurs by default: "Ç" is char 128 in CodePage
850, and converted to char 199 in CodePage 1252.
 If I do ditto in XyWrite with "1252" (the default) on the
command line, I also get "This is a Cedilla Ç" in MSWord
(because "1252" on the CMline is the same as the default,
i.e. no CMline argument [or, anyway, no CMline argument that
CLIP considers relevant -- you would only need to be
concerned about the content of your CMline if it consisted
entirely of numbers -- that could confuse CLIP fatally]).
If I do ditto in XyWrite with "850" on the command line,
when I Paste in MSWord I get "This is a Cedilla ?". Note
that the cursor must be in text, otherwise I would Copy the
string "850", duh.
The logic of this (which can be confusing, but is intended
to be as flexible as possible) is:

A command line argument (437|850|1252, default=1252) represents:
 the target CP when Copying from XyWrite
   or
 the source CP when Pasting to XyWrite
Thus, when you Copy a Cedilla but put "850" on the CMline,
the assumption is that you will put char 128 (not 199) in
the *target* app, which *should* be *another 850 app*! But
if by mistake you Paste into a 1252 app like MSWord, you
will get char 128 (? in CP1252) instead of char 199 (Ç in
CP1252). Another way to think of this is that if you put,
on the CMline, the current CodePage number of XyWrite, the
character *numbers* that you copy will be exactly preserved
(with the attendant danger that if you copy into an app in a
different CodePage, you may get very different characters
than XyWrite displayed). Power = Complexity.
In sum, the default is interaction between XyWrite (437|850)
and a Windows application (1252). But all other
combinations are available. E.g.: ANSIfied XyWrite runs in
1252; and the target app may operate in any of the three
CodePages. (Indeed, I seem to recall that I built this
application to enable ANY single-byte character set (SBCS)
CodePage to be argued, not just 437, 850, or 1252.)
Note that, on NT anyway, the underlying Unicode API is
smart. It sometimes seems to know on its own what CodePage
the current app uses, and converts to that CodePage
automatically, overriding your CMline argument. This can
happen, e.g., on the DOS command line (I am not going to
reboot right now, just to determine whether that happens
because I always explicitly use a CHCP argument when I boot
my Win2K machine). You need to experiment.
≪
Now I too am having problems with smart quotes, and will
need to take some time I don't have right now to test
systematically. But I THINK there may be a problem with
those particular characters, in that there may not be an
agreed-upon standard way of encoding them. Anyone else
remember that? Or am I finding the mare's nest by pursuit of
the red herring again.

--
Patricia M. Godfrey
PriscaMG@xxxxxxxx