Re: DOS v Win encoding

[Wolfgang Bechstein bechstein@xxxxxxxx]

"Robert Holmgren"  wrote:

> I have this
> problem: I can't reproduce your conditions, nor can I see where
> your problems with Clip are manifest. Can you give me an exact
> scenario where Clip doesn't work? Give me one word you're
> trying to copy/paste. What app are you trying to Paste to?
> Copy from? An app that I might have...

Well, I gave examples in my original query. Here they are again (with
some added version info for the apps). In order not to confuse, I am not
using quotes or anything here, but the line following each explanation
(after the colon) is _exactly_ what I am using and what I get.
Please note that this mail is encoded in UTF-8. It should be reproduced
correctly by an appropriately equipped mail client.

Test sentence in XyWrite 4 for DOS, version 4.018, code page 437:
Some umlauts and es-zet ä ü ö Ä Ö Ü ß followed by lower-ASCII
text

After pasting (via CLIPWC in Xy and then normal Windows paste
from clipboard) into MS Word 2000, Japanese version:
Some umlauts and es-zet 1
(the string is lopped off at the first character that is not lower ASCII,
ending with a "1" that was not there in the original)

Test sentence in MS Word 2000, Japanese version:
Some umlauts and es-zet ä ü ö Ä Ö Ü ß followed by lower-ASCII
text

After pasting (via Windows copy to clipboard and then CLIPWP
in Xy) into XyWrite 4 for DOS, version 4.018, code page 437:
Some umlauts and es-zet a u o A O U s followed by lower-ASCII text
(string is not truncated but umlauts are stripped and turned into lower ASCII)

Pasting between the Windows clipboard and XyWrite works perfectly fine
in both directions as long as the entire string is in lower ASCII. But
anything that contains, say, an umlaut or another character above ASCII
126 gets truncated (not only does the offending character get gobbled,
anything after it, even if lower ASCII, also never arrives when pasting
from XyWrite to Windows. The end of the copied string is always a
spurious "1".) When going in the other direction, the string does not get
truncated but "higher ASCII" is turned into lower ASCII characters.

I don't suppose you have Japanese MS Word, and I don't have the
non-Japanese version, but the result of the paste operation in Windows
is the same for example in Notepad++ (the editor I use as my Notepad
replacement, a non-Japanese app) or in UltraEdit-32 (another
non-Japanese app) or in BabelPad (nice freeware Unicode text editor), so
I don't think the actual app in Windows matters. Rather, it is most likely to
do with the way the clipboard operates in Japanese Windows.

So far, I have tried your test for installed code pages, and using the
code page argument when copying to the clipboard in Xy.

Here are the results of the latter:

CLIPWC 1252
Message line in Xy shows "Clipped 66 bytes" (same as when using CLIPWC
without an argument), and behavior is as described above (lower ASCII
gets copied fine, but string is truncated with "1" at first umlaut)

CLIPWC 65001
Message line in Xy still shows "Clipped 66 bytes" but apparently
_nothing_ (or NULL?) gets placed into the Windows clipboard. Pasting in
any Windows app produces nothing (not even the previous clipboard
content).

CLIPWC 1200
Same as for 65001

If you have any other arguments or different versions of CLIP for me to try out, I
would be most happy to oblige.

Thanks so far,

Wolfgang Bechstein