Created attachment 47456 [details] Windows platform. There is a user complained that copying Odb file (using Traditinal Chinese) data to Calc has characters which are encoed wrongly. You can get the file at here: https://docs.google.com/leaf?id=0B9JKiYcC-SFQMDIwNjA5ODItMzFkOC00M2M3LTgxYTUtMDc4NmEwYzY2YWMy&hl=en_US&authkey=CMqpnt0H I tested LibO 3.4 RC2, the problem do exist. But the problem does not occur on LibO 3.3.2 Linux platform. See the attachments for output of Windows platform (having bug), and Linux platform (having no bug).
Created attachment 47457 [details] Linux platform
In all, the copying action from Base will produce characters which are not eoncoded well (http://en.wikipedia.org/wiki/Mojibake) in Calc of Windows, but not in Calc of Linux.
I could not reproduce the error on Windows with LibreOffice 3.4.0. Can you please give the steps you made? It works well via Data Sources (F4) in Calc, also copy & paste strings from Base works.
I use the mehtod in this blog post: http://openoffice.blogs.com/openoffice/2007/04/farrrrrr_simple.html Go to "Table" first, then right click the Data I would like to "Copy" to Calc. This would create Data in wrong encoding. Plus, drag the Data icon directly and drop to Calc, the problem can also be avoided.
RC2 is bit by bit identical with release version, so separate items in the version picker are useless. Changes have been discussed with Michael Meeks.
It is not fixed yet in 3.4.2 RC3. Andras, could you verify this bug again? Thanks.
*** Bug 40766 has been marked as a duplicate of this bug. ***
Is the bug still there on 3.4.4 ? What's the font and encoding to use to test ?
It is still there. I don't know actually the encoding is, but Chinese (Traditional) Windows usually use "big5" as default. The problem only exist when you use the "Copy" item of the context menu to paste on Calc. However, it you open Calc first, and drag the table in odb file directly to the Calc, and everything is fine. This is the expected output.
Repruduced. Windows XP 32 bit LibO 3.4 russian language Problem is more interesting than expected. When I copied table from database and inserted it into Calc, it inserted without problem. Then I changed one field in database to text on russian (Cyrillic) , copied table and inserted to Calc. All except russian inserted ok, but russian text looks wrong. To reproduce this looking of russian text manually, I have saved document with russian text as text in Windows encoding, then opened it in webbrowser and changed encoding to ISO-8859-1. Characters become looking as described above problem. Therefore it is locale-specific problem. This bug resembles Bug 39890
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
The bug is still there. Using the mehtod in this blog post: http://openoffice.blogs.com/openoffice/2007/04/farrrrrr_simple.html Go to "Table" first, then right click the Data I would like to "Copy" to Calc. This would create Data in wrong encoding. Plus, drag the Data icon directly and drop to Calc, the problem can also be avoided.
The data formats for both RTF and HTML contain certain text in a system default encoding, but it is either marked as a charset 0 or windows-1252.
Possibly related to Bug 36144
The culprit probably is /core/dbaccess/source/ui/misc/TokenWriter.cxx:421 Also, the logic here seems strange to me: /core/svtools/source/svrtf/rtfout.cxx:118
Any update with last LO stable version, 4.2.5?
Bug existed, reproducible on 4.3.0.
Cheng-Chia: Thank you for your feedback, put it back to NEW.
I can confirm the issue, exactly as described elsewhere in this thread, except this time for Greek fonts. Libreoffice Version: 4.3.0.4 Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0 on Windows 7 Pro
Please see this Bug 79631 where it seems that Dominik has tackled the issue in version 4.4.0.0.alpha0+ . And apologies for having forgotten my own submission...
On pc Debian x86-64 with 4.3.2 Debian package, I don't reproduce the very similar fdo#79631 put in See Also Cheng-Chia: Since, I don't have Google account, could you give a new try with 4.3.2 version?
As reported, this bug only existed on Windows platform. Linux is not affected. You can get the file at https://www.dropbox.com/s/tbb7bgffees5igj/%E5%B7%A5%E7%A8%8B%E7%AE%A1%E7%90%86%E8%B3%87%E6%96%99%E5%BA%AB2.odb?dl=0 Tested with version 4.3.2 on Windows 7 64bit, this long life bug exists still.
If one needs another file for testing, the attachment in bug 79631 does the trick. It is a small odb file containing a single table with fonts in various encodings exhibiting the issue. Here is the link: https://bugs.freedesktop.org/attachment.cgi?id=100392
The text in the 'system' encoding on Windows is copied to RTF as ANSI. It is marked by a font with \charset0. That is what causes the issue.
*** Bug 79631 has been marked as a duplicate of this bug. ***
If you want to reproduce it, you will need a Windows OS set to any legacy codepage than 1252. P.S. Bugs do not fix themselves by magic after two years.
Urmas: bug may indeed be "magically" fixed sometimes when: - a similar bug has been fixed - some code part has been redesigned - a problem indicated by code analyzers (like coverity scan, cppcheck and other), which was the root cause of the bug, has been fixed etc. Of course, I wouldn't be able to give you any probalities but it does happen sometimes! :-)
Adding self to CC if not already on
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.