Created attachment 90281 [details] A sample emf file that loads incorrectly, as well as a .bmp of the correct rendering and a .png of the incorrect rendering from 4.1.3.2 Problem description: Figures copied from matlab and pasted into impress and writer and draw lose the actual trace data. Same for figures saved as .emf files and then dragged-and-dropped into libreoffice. Libreoffice files that had such figures pasted into them pre 4.1.3.2 still load correctly. I've attached a sample .emf file and samples of what it should look like and how it renders. When pasted into libreoffice, the blue trace data disappears. Current behavior: Blue trace disappears Expected behavior: Emf file renders correctly. Operating System: Windows 7 Version: 4.1.3.2 release
TESTING on Ubuntu 12.04.3 with LibreOffice Version: 4.2.0.1 and LibreOffice Version: 3.5.7 (In reply to comment #0) > Problem description: > Figures copied from matlab and pasted into impress and writer and draw lose > the actual trace data. Same for figures saved as .emf files and then > dragged-and-dropped into libreoffice. > > Libreoffice files that had such figures pasted into them pre 4.1.3.2 still > load correctly. Repro steps: 1) Download and unzip file sample_files.zip 2) Open sample.emf and sample_correct.bmp in LibreOffice 3) Compare the two documents as displayed by LO In 3.5.7: Both display a blue graph In 4.2.0.1: Only the BMP displays w/a blue graph Keywords: regression Thanks for the bug report!
OS: All Bumping priority for regression
Hi guys, we have also experienced this problem and it seems to be cross-platform present. It appears also on LibreOffice 4.2.0.4 on Debian amd64 (TDF builds) and Windows 7 64-bit (with LibreOffice 4.0.6). But, what might be important, this bug affects only Matlab generated EMF files. EMFs from the GNU/Octave are imported correctly. Two samples are attached - they are generated by the same script. P.S. Something that may help to other users experiencing this problem - EPS files work fine.
Created attachment 93101 [details] EMF file generated by GNU/Octave (imported OK)
Created attachment 93102 [details] EMF file generated by Matlab (imported broken)
broken since 4.1.0.4
still buggy
Karel: Seen your comment on openoffice.cz :-) - would be tremendously helpful if you can bibisect this bug, to see what broke this. Can you please do that? Bibisect howto: https://wiki.documentfoundation.org/QA/HowToBibisect You probably want to use one of the repositories that have a long history, like 43all. Thank you in advance!
Hi Jan, I'll try that, but we'll see how much time will it take (I never did something like that). Thanks for hint! Karel (In reply to comment #8) > Karel: Seen your comment on openoffice.cz :-) - would be tremendously > helpful if you can bibisect this bug, to see what broke this. Can you > please do that? > > Bibisect howto: https://wiki.documentfoundation.org/QA/HowToBibisect > > You probably want to use one of the repositories that have a long history, > like 43all. Thank you in advance!
Hello once again, I am sorry for the delay, I had to set up a Ubuntu 12.04.0 virtual machine, since I was not able to bibisect 43all on Debian Wheezy nor openSUSE 12.2. The results are very impressive - it seems, that the bug will be fixed in LO 4.3, so I tried to find the progress of the bug. It has been pulled into LO by this commit: a7e54955e9f49e8b59dfd8c4533785a680b1796c is the first bad commit commit a7e54955e9f49e8b59dfd8c4533785a680b1796c Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed Oct 16 11:07:50 2013 +0000 source-hash-5da10275a7475efdbfd9de14ea58cf8f4c6c1582 commit 5da10275a7475efdbfd9de14ea58cf8f4c6c1582 Author: Stephan Bergmann <sbergman@redhat.com> AuthorDate: Fri Mar 1 17:09:45 2013 +0100 Commit: Stephan Bergmann <sbergman@redhat.com> CommitDate: Fri Mar 1 17:18:29 2013 +0100 Related rhbz#915743: Abort UCB call from SvtMatchContext_Impl::Stop ...as otherwise the SvtMatchContext_Impl thread can continue to run for arbitrarily long, and the other thread calling Stop() and join() will block. However, especially the WebDAV UCP does not properly support aborting commands, see 260afe56fd6b2f34de8290f3cdb7d1df5b88f8a8 " neon commands cannot be aborted", so this is not yet enough to actually fix rhbz#915743 "thread deadlock/slow join in insert->hyperlink in impress." Change-Id: I0da899f824763e1b3d19bb5b38d906feb690b623 :100644 100644 fd22aadcebcf1ca20b6c2fcdb9e135deeb9b5885 8a0f14e1bb71d7ecdf8086c62e9769bb7f2d09b8 M autogen.log :100644 100644 5af869ab53b50329a270e7d4e2587f802bf68afb 8519bf956c5e06a85818d380070eedc0ef846790 M ccache.log :100644 100644 63cd7351c9d6feb098661a5783d51bb172d8a306 33abac29aad7182260562465482b493d94b78a83 M commitmsg :100644 100644 e9ea867065a69fa4f0fbbb5c2abb40baeeabd307 21fc5294b2cb922862b78327b6b8a3cd953f38b5 M dev-install.log :100644 100644 4c087a5ff52a8cef08f31417ac650666b1d9d0af c1cc87465560a589137349c81641a62968242386 M make.log :040000 040000 ece742cbaf9101d015210ea8da6c00ad7a4457c7 9ff9cbceea1fe6b0ad1b17fe9068b2c8e32a6cbb M opt and repaired by this one (I processed the bibisect on search for the repairing commit as negation, so you must negate also the answer from bibisect :-) ): 426fdcf0b13134ffbc7f92900d5862fad3723192 is the first bad commit commit 426fdcf0b13134ffbc7f92900d5862fad3723192 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue May 20 17:11:31 2014 +0000 source-hash-c9f3c508bb1a1d94fd6172b9cdac30278559f31c commit c9f3c508bb1a1d94fd6172b9cdac30278559f31c Author: Tsutomu Uchino <hanya@apache.org> AuthorDate: Sat May 17 09:39:39 2014 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Mon May 19 08:57:45 2014 +0100 Resolves: #i76558# jump by Enter key on the Object catalog (cherry picked from commit 7bc75c1a7b05d81631ebccf05bf022636d1a3a14) Conflicts: basctl/source/basicide/objdlg.cxx basctl/source/basicide/objdlg.hxx Change-Id: Id3fa3686fd60df192c02cc8137c9bc59e68c1d49 :100644 100644 7d3650d96243db82f932a21ee4626214b4495cea 501fbfa427b8a231fe035cd8c6c9861d0483e887 M ccache.log :100644 100644 cf5388c2c897a4c7275ea71a8391cd28f9d61951 94e1769dda5ee27e4952754e43c4d26fe19c2009 M commitmsg :100644 100644 7afde8b8b64a5ced588820ae9d0e52c7d8054eff 8c966b034e7c757c8922b3ba931bd93077f23e64 M make.log :040000 040000 ddeb76d5a90380df40242d58c9aac5fbbcd346c8 5f3414102b71bcb5a2c7f817d6502959169c4345 M opt Would it be possible to backport the fix into 4.2 branch? Thank you all! (In reply to comment #8) > Karel: Seen your comment on openoffice.cz :-) - would be tremendously > helpful if you can bibisect this bug, to see what broke this. Can you > please do that? > > Bibisect howto: https://wiki.documentfoundation.org/QA/HowToBibisect > > You probably want to use one of the repositories that have a long history, > like 43all. Thank you in advance!
Created attachment 100440 [details] Rendering in LibreOffice 4.3.0.0 beta1 Maybe I was too enthusiastic about fixing the bug, so I did not notice different rendering under LO 4.3.0 - it seems, that the patch repaired rendering of graphical dependencies, but rendering of dashed lines in grid is corrupted now. I'll try to bibisect this.
The result of bibisection is bad: There are only 'skip'ped commits left to test. The first bad commit could be any of: 67ae616bc846d2a4e05661a5980287cb38b8a455 bde12e7d6eef3d657ebdf62cb5442490fb90d899 7faf01595aded0c825d2d9e50c62c688e91c1496 We cannot bisect more! I was not even able to run these builds (ERROR 4 forking process). Should I create a separate bug report for this or is it possible to solve it together with rendering of graphical dependencies? (In reply to comment #11) > Created attachment 100440 [details] > Rendering in LibreOffice 4.3.0.0 beta1 > > Maybe I was too enthusiastic about fixing the bug, so I did not notice > different rendering under LO 4.3.0 - it seems, that the patch repaired > rendering of graphical dependencies, but rendering of dashed lines in grid > is corrupted now. I'll try to bibisect this.
(In reply to comment #12) > The result of bibisection is bad: > ... > I was not even able to run these builds (ERROR 4 forking process). Should I > create a separate bug report for this or is it possible to solve it together > with rendering of graphical dependencies? AFAIK we don't currently test builds to make sure they will successfully run prior to adding them to a bibisect repo. We hope that the number of non-running builds remains small relative to the size of the repo. If you're unable to finish bibisecting a bug for technical reasons, please feel free to make an note on the bug report, leave it for the developers or other QA folks, and move on to the next bug in the list. If you'd like to proceed further, you can try to build and run suspect versions based on what bibisect has provided.
(In reply to comment #13) > (In reply to comment #12) > > The result of bibisection is bad: > > ... > > I was not even able to run these builds (ERROR 4 forking process). Should I > > create a separate bug report for this or is it possible to solve it together > > with rendering of graphical dependencies? > > AFAIK we don't currently test builds to make sure they will successfully run > prior to adding them to a bibisect repo. We hope that the number of > non-running builds remains small relative to the size of the repo. > > If you're unable to finish bibisecting a bug for technical reasons, please > feel free to make an note on the bug report, leave it for the developers or > other QA folks, and move on to the next bug in the list. If you'd like to > proceed further, you can try to build and run suspect versions based on what > bibisect has provided. Actually I am not sure if I expressed myself well - I did not mean a bugreport about non-running builds, but about bad rendering of dashed lines (from the attachment: https://bugs.freedesktop.org/attachment.cgi?id=100440).
(In reply to comment #14) > Actually I am not sure if I expressed myself well - I did not mean a > bugreport about non-running builds, but about bad rendering of dashed lines > (from the attachment: https://bugs.freedesktop.org/attachment.cgi?id=100440). If you think that the bad rendering of dashed lines is indicative of a separate problem from what's described in this bug report, then please do file a separate bug report. If you think that they're both caused by the same underlying problem, then I would suggest you add an additional repro step in a comment so that the devs can use that test to confirm whether a particular patch fixes this bug.
(In reply to comment #15) > (In reply to comment #14) > > Actually I am not sure if I expressed myself well - I did not mean a > > bugreport about non-running builds, but about bad rendering of dashed lines > > (from the attachment: https://bugs.freedesktop.org/attachment.cgi?id=100440). > > If you think that the bad rendering of dashed lines is indicative of a > separate problem from what's described in this bug report, then please do > file a separate bug report. If you think that they're both caused by the > same underlying problem, then I would suggest you add an additional repro > step in a comment so that the devs can use that test to confirm whether a > particular patch fixes this bug. I think it is a separate problem (also it was caused by another commit), so I created a new bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=79679 Thank you for cooperation!
this commit is responsible both for fixing the drawing of the curves *and* for the grid lines disappearing at zoom levels 80%-140% commit fc83bf8bbf813fff1cb7c0b7925976bc43a49f94 Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> AuthorDate: Sun May 18 23:30:39 2014 +0200 fdo#72590 scale or map only when EMR_EXTSELECTCLIPRGN action
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
sounds like both issues got fixed needs verification
(In reply to oliverdial from comment #0) > Created attachment 90281 [details] > A sample emf file that loads incorrectly, as well as a .bmp of the correct > rendering and a .png of the incorrect rendering from 4.1.3.2 > > Problem description: > Figures copied from matlab and pasted into impress and writer and draw lose > the actual trace data. Same for figures saved as .emf files and then > dragged-and-dropped into libreoffice. Have you tried to get assisted by third party experts? I assume MATLAB assignment help cost is not high. Check https://assignmentcore.com/matlab-homework/, hope someone from this company helps you render the files correctly.