On Mon, 22 Jul 2002 [EMAIL PROTECTED] wrote:
> On Linux just one side work fine > -) Copy from OpenOffice (by CTRL-C) and Paste to Yudit (by CTRL-V) Using the mouse also works fine from copy'n'pasting arbitrary Unicode strings from OO to Yudit. > An other detail => When I copy from OpenOffice (by CTRL-C) the > word > <apple> and then I copy from Yudit (by selection) the word <peach> > and them I Paste to OpenOffice (by CTRL-V), I obtain the wrong > word > <apple> if I use Linux, I wouldn't say it's wrong, but rather in a different representation. Apparently, when asked for 'STRING' and 'COMPOUND_TEXT' target, yudit uses '\uxxxx' representation of Unicode character U+xxxx not representable in STRING and COMPOUND_TEXT. What's reprsentable in STRING and what's not is very clear. Anything beyound U+00FF(Latin-1 repertoire) is not representable in STRING. As for COMPOUND TEXT, I'm not sure. > Have you an other text formatting editor on Linux with right > Copy-Paste > mechanism to and from Yudit. xterm 16x <-> openoffice, xterm 16x <-> yudit and Mozilla <-> (xterm 16x, yudit) work very well for a paragraph of Cyrillic alphabets, Greek alphabets, CJK Ideographs(not covered by a single legacy character set), Hangul syllables, Hangul Jamos. xterm 16x, yudit and Mozilla are all known to support UTF8_STRING. However, Mozilla <->OO works in some cases but not always. Given all these, it's not clear whether or not OO supports UTF8_STRING. Because even if it does not, I think COMPOUND_TEXT can be used to exchange arbitrary Unicode strings using 'ESC %G' representing the beginning of UTF8 and that's what may be used between xterm-16x and OO and Mozilla <-> OO. I may be wrong. I have to dig up the compound text spec. to be sure. I wanted to search OO bug DB, but I need to be approved for a membership in L10N(for both L10N and I18N) project before even browsing existing bugs, let alone reporting a new one. Jungshik -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
