Issue 43933 - RTF-Export and Clipboard generating invalid characters if desktop locale is UTF-8 [WAS: Clipboard broken: Writer -> EditEngine for any non-latin text]
Summary: RTF-Export and Clipboard generating invalid characters if desktop locale is U...
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: 680m81
Hardware: All Linux, all
: P2 Trivial (vote)
Target Milestone: ---
Assignee: michael.ruess
QA Contact: issues@sw
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-02 19:27 UTC by ulf.stroehler
Modified: 2013-08-07 14:41 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
japanese dummy text (8.47 KB, application/vnd.sun.xml.writer)
2005-03-03 13:53 UTC, ulf.stroehler 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description ulf.stroehler 2005-03-02 19:27:52 UTC 
REPRODUCTION:
=============

1. Copy any CJK or CTL text in Writer to Clipboard
2. Paste into DrawTextObject or Calc

=> Characters are pasted corrupted ("glyph soup")

Note: 
=====

* PrimarySelection aka XClipboard seems also to be affected
* does *not* seem to be reproducible on Win32 (Unix only)
* vice versa: EditEngine -> Writer is ok.

US->AMA: not sure if it's hbrinkm. Pls. dispatch. Thank you.
Comment 1 ulf.stroehler 2005-03-02 19:29:40 UTC 
Changing Component to 'Word processor'.
Comment 2 andreas.martens 2005-03-03 08:43:02 UTC 
Henning, please take care of this issue. Contact HDU, because he had changed
something with glyph fallback.
Comment 3 ulf.stroehler 2005-03-03 10:26:22 UTC 
us->ama: well that doesn't look like a glyphfallback problem to me. Looks more
like an encoding prob.
Comment 4 ulf.stroehler 2005-03-03 13:53:13 UTC 
Created attachment 23293 [details]
japanese dummy text
Comment 5 openoffice 2005-03-03 15:46:22 UTC 
HB->US: Needs further investigation: For me (Debian) it works with locale
de_DE@euro. With de_DE.utf8 it does not.
Comment 6 ulf.stroehler 2005-03-03 18:36:39 UTC 
US->HBrinkm/FLR: thanks Henning. You are right, as seen together with Florian
the RTF Export generates invalid characters if the desktop locale is *.UTF-8. As
the clipboard between OO.o components also utilizes the RTF filter it's obvious
that it can not work correct either.

Changed 'Summary' to better reflect the root cause.
Comment 7 flr 2005-03-11 18:41:20 UTC 
Broken by fix for #i35653#.
Comment 8 flr 2005-03-21 10:23:46 UTC 
reopen for QA
Comment 9 flr 2005-03-21 10:24:03 UTC 
flr->mru: please test
Comment 10 flr 2005-03-21 10:24:18 UTC 
.
Comment 11 ulf.stroehler 2005-03-24 17:07:16 UTC 
Verified in cws 'frrtf02'.
Comment 12 michael.ruess 2005-04-07 10:39:34 UTC 
Checked integration of text in 680m90.
Comment 13 stmatth 2005-04-20 17:11:02 UTC 
This is marked as fixed, but here it is still broken (in 1.9.93) but in a 
different way than before. 
 
1. When I open the exported document in a different programme (kword), then 
spaces after special characters have disappeared (e.g: "daßman" instead of 
"daß man") 
 
2. When I reopen the document with Openoffice, special characters are followed 
by "\uc", like: "daß\ucman das weiß\uc." 
 
Again, only when language setting is UTF8. 
 
Thanks
Comment 14 ulf.stroehler 2005-04-20 17:50:42 UTC 
Thanks stmatth for the hint!

Yes, unfortunately true it's still broken (damn).
Will file a follow-up and cross link the id here.
Comment 15 ulf.stroehler 2005-04-20 18:36:35 UTC 
Follow-up issue is now issue 47831.