Bug 74921 - EMF pictures pasted via clipboard do not show properly if they contain clip regions
Summary: EMF pictures pasted via clipboard do not show properly if they contain clip r...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Bartosz
Depends on:
Blocks: EMF-WMF
  Show dependency treegraph
Reported: 2014-02-13 09:50 UTC by rbruenner
Modified: 2017-05-19 07:28 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

The second image in the file shows the problem. (53.98 KB, application/vnd.oasis.opendocument.text)
2014-02-13 09:50 UTC, rbruenner
Contains a simple test programme for generating EMF content showing the issue (1.08 MB, application/zip)
2014-02-13 13:24 UTC, rbruenner
Updated files and images (250.24 KB, application/octet-stream)
2017-05-10 13:22 UTC, rbruenner
Pictures extracted from EMF ClipRect.odt (39.59 KB, application/zip)
2017-05-10 15:11 UTC, Bartosz

Note You need to log in before you can comment on or make changes to this bug.
Description rbruenner 2014-02-13 09:50:40 UTC
Created attachment 93993 [details]
The second image in the file shows the problem.

An EMF picture which has been created using the SelectClipRgn API does not show properly in Writer. I have tested with LO 3.6 both on Windows 8 Enterprise and on Mac OS X 10.7.5, and with the freshly released LO 4.1.5 on Mac OS X 10.7.5.

The attached file contains a Writer document where an example image of our proprietary software has been included. The first image was inserted from an EMF file on disk. The second image was inserted as an EMF image from the clipboard created using the same drawing code. The third image was inserted from the clipboard using the bitmap format. While the EMF image from the file looks as expected (and similar to the bitmap image), the EMF image from clipboard lacks the content in the graph. It only shows the graph's axes, labels and grid lines.
I noticed that when scrolling using the mouse wheel over image 2 in version 3.6, the content in the graph partially showed up and disappeared again after scrolling further. In version 4.1, this was no longer the case.

Steps to reproduce: Open the attached file. Using LO 3.6, scroll down using the mouse wheel. The graph of picture 2 is empty. At the end of the document, scroll up. You can see the graph of picture 2 partially. When scrolling down again, the graph in picture 2 is empty again. In version 4.1.5 it is always empty. The same is true for the Page Preview.

I was able to identify the responsible code for this behaviour. Between drawing the graph and its contents, there are calls to the SelectClipRgn API. This has been done so that "overdrawing" beyond the limits of the graph rectangle was avoided. In an experimental build of the software, I omitted the clipping calls and the EMF was displayed in all three cases mentioned above. However, clipping is necessary in most cases in order to display the image properly, so leaving it out in production code is not an option for us.

From the findings, I suspect that the EMF records for selecting the clip rectangle might not be processed correctly in all cases.
Comment 1 rbruenner 2014-02-13 13:24:49 UTC
Created attachment 94002 [details]
Contains a simple test programme for generating EMF content showing the issue

With the test programme, you may create EMF clipboard content which shows this problem easily - just press the Copy icon on the toolbar. The image shows a black filled rectangle and a red line. There is also a blue diagonal line of the same length as the red one, but which is clipped to the rectangle area. This line is not properly handled by LO.

The attachment also contains the VC++ project with the source code for your reference.

It is interesting that the bug disappears when line 162 in EMFTestView.cpp is commented out:
I am not quite sure whether this call is redundant or not, however, in the presence of this call, the drawings after applying the clipping rectangle do not work properly.
Comment 2 Yousuf Philips (jay) (retired) 2014-07-07 06:18:42 UTC
Hello rbruenner,

I can confirm that 3.3 & 3.6 to 4.1 for image 1 has grid lines if at my screen resolution, i zoom to 120%. grid lines appear in image 2 if i zoom to 90%.

In 3.6, if i scroll up and down, portions of image 2's missing red lines do appear.

4.2 and above will not show the grid lines at any zoom level or the red lines at if scrolling up and down.
Comment 3 QA Administrators 2016-02-21 08:37:05 UTC Comment hidden (obsolete)
Comment 4 rbruenner 2016-04-18 06:58:06 UTC
Tested again with LO 5.1.2.on Mac OS X 10.10.5 using the very same document.
The bug is still there. Both EMF from file and inserted as bitmap display correct. EMF inserted as GDI MetaFile does not show properly.
Comment 5 Bartosz 2017-05-09 01:30:26 UTC
Could you please attach the emf image, which cause the issue. 
I have only Linux OS, and I'm not able to generate this EMF file.
Comment 6 rbruenner 2017-05-10 13:22:20 UTC
Created attachment 133214 [details]
Updated files and images
Comment 7 rbruenner 2017-05-10 13:38:53 UTC
Hello Bartosz,

thanks for looking into that issue. As I have reported, the problem in the document only arises for clipboard-copied GDI metafile content. So an EMF file will not exactly help here.

It does seem that the odt file does not contain the proper metafile content for the copied image. The image inserted from EMF file looks complete.

I took the opportunity to redo the example.
With LO 5.1.6 on Windows 10, both images (the metafile from file and the metafile from clipboard) now produce identical results in a new document. (See attached odt file.)
The visibility problem has actually disappeared, but for newly generated files only. Old files, however, still show this issue. (Information is permantently lost in documents from previous versions?)

When comparing to the bitmap image on the second page (which looks like the metafile content should look like), the Windows version seems to use a slightly different font and an extra wide letter spacing. The Mac version, however, is using the correct font but all texts not left-aligned are wrong. The tick labels of the y axis are right-aligned and they are reversed on Mac OS. The tick labels of the x axis are centred relatively to the ticks and are overprinted on the Mac OS output.

I have included screenshots for both systems.

Best regards
Comment 8 Bartosz 2017-05-10 15:11:13 UTC
Created attachment 133215 [details]
Pictures extracted from EMF ClipRect.odt

I extracted images from EMF ClipRect.odt and it contains three files:

The image which is not displayed correctly is 200000D7000070AC00005493CA130097.svm
I don't know know if it possible to fix this image. Most propably by converting from wmf/emf to svm, the informations were pernamentely lost.

In file EMF via clipboard.odt, there is only two images:

So it seems that wmf is used in both cases: the metafile from file and the metafile from clipboard.
I don't know what I we could do else with this issue. The problem was resolved for newly created files, and it seems that old files are pernamenately corrupted.

Maybe we should close this bug?
Comment 9 Bartosz 2017-05-10 15:16:02 UTC
It looks like the .SVM file extension is OpenOffice image type, which stores vector and raster graphics when inserting or copying images between the different programs of the respective suites.

My assumption is that LibreOffice opens correctly its own SVM files.
It means that old files were pernamentely corrupted.
Comment 10 Bartosz 2017-05-19 07:28:48 UTC
It looks like the issue was resolved with LibreOffice 5.4.
If you have other issues with importing EMF files, please create new ticket, and let me know about it :-)
Closing as resolved