Download it now!
Bug 72324 - EMF: figures copied from Matlab and pasted as metafiles lose some lines.
Summary: EMF: figures copied from Matlab and pasted as metafiles lose some lines.
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: Other All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2013-12-04 21:06 UTC by oliverdial
Modified: 2016-04-23 09:22 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
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 (33.76 KB, application/x-zip-compressed)
2013-12-04 21:06 UTC, oliverdial
Details
EMF file generated by GNU/Octave (imported OK) (146.41 KB, image/x-emf)
2014-01-31 07:59 UTC, Karel Hruska
Details
EMF file generated by Matlab (imported broken) (33.43 KB, image/x-emf)
2014-01-31 08:00 UTC, Karel Hruska
Details
Rendering in LibreOffice 4.3.0.0 beta1 (170.69 KB, image/png)
2014-06-05 06:50 UTC, Karel Hruska
Details

Note You need to log in before you can comment on or make changes to this bug.
Description oliverdial 2013-12-04 21:06:36 UTC
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
Comment 1 Robinson Tryon (qubit) 2013-12-22 19:27:46 UTC
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!
Comment 2 Robinson Tryon (qubit) 2013-12-22 19:28:21 UTC
OS: All

Bumping priority for regression
Comment 3 Karel Hruska 2014-01-31 07:58:30 UTC
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.
Comment 4 Karel Hruska 2014-01-31 07:59:21 UTC
Created attachment 93101 [details]
EMF file generated by GNU/Octave (imported OK)
Comment 5 Karel Hruska 2014-01-31 08:00:09 UTC
Created attachment 93102 [details]
EMF file generated by Matlab (imported broken)
Comment 6 Michael Stahl (CIB) 2014-02-03 13:29:22 UTC
broken since 4.1.0.4
Comment 7 Ravi 2014-04-18 17:20:42 UTC
still buggy
Comment 8 Jan Holesovsky 2014-06-04 08:22:03 UTC
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!
Comment 9 Karel Hruska 2014-06-04 09:06:07 UTC
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!
Comment 10 Karel Hruska 2014-06-05 05:56:04 UTC
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!
Comment 11 Karel Hruska 2014-06-05 06:50:35 UTC
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.
Comment 12 Karel Hruska 2014-06-05 07:11:18 UTC
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.
Comment 13 Robinson Tryon (qubit) 2014-06-05 08:55:31 UTC
(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.
Comment 14 Karel Hruska 2014-06-05 11:39:44 UTC
(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).
Comment 15 Robinson Tryon (qubit) 2014-06-05 11:56:49 UTC
(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.
Comment 16 Karel Hruska 2014-06-05 12:25:44 UTC
(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!
Comment 17 Michael Stahl (CIB) 2014-06-10 15:11:03 UTC
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
Comment 18 Robinson Tryon (qubit) 2015-12-13 11:09:37 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]
Comment 19 JoNi 2016-04-23 09:22:46 UTC
sounds like both issues got fixed

needs verification