Created attachment 40926 [details] Test kit, please see original report! My "LibreOffice 3.3.0 RC1 - WIN XP German UI [OOO330m17 (build 3.3.0.1" leaves a completely crippled result when I copy / paste special - GDI Metafile from a speradsheet. Please compare result in "copypasteresult.odt" (and screenshot in same document) with original table in "sample.ods" sheet "Reparatur_Erforderlich"! Steps to reproduce: 0. Unzip testkit 1. Open new WRITER document and save in same folder as "sample.ods" 2. open "sample.ods" 3. go to sheet "Reparatur_Erforderlich" 4. 'Click A1' 5. Use vertical scroll slider to get 'J17' visible 6. <shift> + <left click> into 'J17' 7. <cntrl>+<c> for "Copy" 8. switch to new WRITER document 9. Icon 'Paste -> as GDI Metafile' Expected: Pasted Table looks very similar to original in one spreadsheet Actual: heavy damages as shown in Screenshot in "copypasteresult.odt" Only a vague suspect: related to or same roots as "Bug 32213 - [EDITING]: Paste Unformatted Text broken for complex cell contents" I have been doing so for years with OOo, never saw such problems.
No Problem when I paste from Spreadsheet opened in LibO to empty WRITER document in OOo 3.1.1 (WIN XP).
It's more serious than I thought, it seems that the rendering under WIN is competely broken for such speradsheets. Steps to reproduce: Do as per original report but in step 9 "paste as CALC8" Unexpected: looks as pasted as GDI Now double click on pasted contents to get to spreadsheet edit mode, and everything looks fine. Now scroll down and click into document somewhere outside pasted table contents, and nonsense view will reappear again. For me LibO is completely unusable with that problem.
May be "Critical" is a little too much my personal opinion ... I see the same problem in "Ooo-Dev 3.4.0 multilingual version English UI WIN XP: [OOo300m95 (Build 9553)]"
Only for the sake of completeness: Also crippled when I paste clipboard contents into LibO DRAWing and PRESENTATION. Same clipboard contents works fine when I paste it into OOo 3.1.1 DRAWing or PRESENTATION. This is a new effect, worked fine with "LibreOffice 3.3.0Beta3 - WIN XP DE [OOO330m12 (build 3.2.99.3)]" NEW because on my laptop problem started after Installation of RC1 (but worked fine with Beta3)
Assigned
And even worse, also DRAW and WRITER objects are affected, please test with - DrawSample.odg (Mark object, <cntrl>+<c>, Paste special / als DRAW 8 object into a new WRITER document) - WriterSample.odt (<cntrl>+<a>, <cntrl>+<c>, Paste special / als LibO Text Document into a new DRAW document) You will see those line repetitions instead of correct text. Might be interesting to see whether other OS are affected. Definitively not as SPREADSHEET problem. Current OOo versions also are affected, pls. see <http://www.openoffice.org/issues/show_bug.cgi?id=116005>
Created attachment 40979 [details] Please see Comment 6 for details!
On [tdf-discuss] user Sveinn í Felli told me that there seems to be no problem with Fedora 13 64bit
Did the test on Fedora 13 64bit without any problems.
Not specially a windows problem: I could reproduce it on Linux too. Radek, would it be your area?
I also test the bug on my updated OpenSuSE 11.2 x86-64, Gnome 2.30.2 (also installed KDE 4.5.4) with: - LibreOffice 3.3.0, OOO330m17 (Build:3), libreoffice-build 3.3.0.1, linux x86-64 (OpenSuSE Build Service release from here: http://download.opensuse.org/repositories/LibreOffice:/Unstable/ rc1 said) - OpenOffice.org 3.3.0, OOO330m17 (Build:9551), linux x86-64 (vanilla one, rc7 said) *testkit* results - Both OOo and LO works fine (!) - and also your "copypasteresult.odt" opens fine (!!!), Windows port rendering trouble? *AdditionalTestKit* results - pasting all "WriterSample.odt" content into Impress / Draw (both tested): -- both OOo and LO works the same; -- text is *badly* rendered: only the first text line is rendered in the Writer object inside Impress / Draw and that line is repeated n times (as you already pointed out); -- this behavior is the same also running the presentation in Impress. - pasting Draw object into Writer / Impress -- both OOo and LO works the same; -- text is *badly* rendered: the first line of each paragraph is repeated n times, where n seems to be exactly the number of lines in which each paragraph is rendered in the original Writer / Impress object (!!!); may be some programming counter/pointer has been forgotten and not updated so that only the first line paragraph is copied n times? -- this behavior is the same also running the presentation in Impress. I will post these test results both on OOo and LO bugs asap. HTH, Carlo
Known bug in OOo : http://www.openoffice.org/issues/show_bug.cgi?id=115825 One of the last stoppers for RC7. JBF
*** Bug 32314 has been marked as a duplicate of this bug. ***
Its a trivial enough bug, introduced in m16 or there abouts. Multi line wmf text records are having the chunks after line 1 effectively rejected as out of scope.
fixed up now
*** Bug 32204 has been marked as a duplicate of this bug. ***
I'm sorry, but the bug is still alive and kicking in LibO 3.3.0 m17 (Build:3) libreoffice-build 3.3.0.1 on my iMac Intel with OSX 10.6.5 GDI-metafile imported in Writer shows several cells with repeated lines instead of conrinuous text - just as OP reported (Rainer Bielfeld testkit). Or is there a fix/patch in newer version?
@Guy Voets: You are using the same build version as I used for my report - of course that can't be fixed for you! @Caolán: Are there any plans to provide information in what code snippets fixes have been integrated and for what LibO version that will be integrated? For me "Environment Information System" from OOo was very useful for such questions.
We'd don't currently have a slot to record the next version that will include the fix. Though it should be the next RC available. Probably best to raise "how to know what version will have a fix included" as a topic on the mailing list.
No longer reproducible with "LibreOffice 3.3.0 RC2 - WIN XP German UI [OOO330m18 (build 3.3.0.2)]" and test kit.
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.