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.
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: <code> OnPrepareDC(&dcClient); </code> 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.
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.0) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
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.
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.
Created attachment 133214 [details] Updated files and images
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
Created attachment 133215 [details] Pictures extracted from EMF ClipRect.odt I extracted images from EMF ClipRect.odt and it contains three files: 1000000000000443000003315260133E.png 200000D7000070AC00005493CA130097.svm 200000D4000034F00000234DEC2327BB.wmf 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: 100000000000058600000427D451DAA0AE3B8933.png 200000E00000C4C700006EBC07F386C866257A75.wmf 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?
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. https://fileinfo.com/extension/svm My assumption is that LibreOffice opens correctly its own SVM files. It means that old files were pernamentely corrupted.
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