Created attachment 48870 [details] Sample Document. Open the Attached Document. Only one Rectangle is drawn which is at the bottom of the screen(class1) Class2 and Class3 should also have a rectangle drawn around them.
Created attachment 48871 [details] What I see on my screen when opening first attachment. I'm sorry, but even though there is likely a problem, I do not think you have provided enough info. Seeing as there is a display problem with LibreOffice, it would have been better if you could have mentioned on which Office Suite for which OS did the rectangles appear properly, and provided an attachment image of the proper appearance so we can have a better idea of what the problem really is. Because it is very hard to verify something that you cannot see. Mentioning that rectangles do not display properly is not good enough to diagnose the situation. Here is what I see: One rectangle is drawn across Class1, 2 and 3. I do not think this is what you meant, because there is no rectangle near the bottom. Can you confirm?
Created attachment 48882 [details] What image should look like Please find attached an Image of what it should like like.
LO 3.4.1 (OOO340m1 (Build:101)) Ubuntu 10.04.2 x86 Linux 2.6.32-32-generic Russian UI Result is different from both images.
Created attachment 48889 [details] Rendering with 3.4 Rendering with LO 3.4
Sorry I forgot to mention my verison: LibreOffice 3.4 340m1(Build:12) for OpenSuse Linux. Still see the same thing that I did in the beginning. I wonder why I do not see the boxes at all...
Not sure if this is related but I've noticed if I create an EMF file with a graphics program I can successfully add it to a .odt document under LibreOffice for Windows. If I then open the same document with LibreOffice Linux/Ubuntu I see a completely garbled odd looking picture where the original image was added. On saving the document under LibreOffice Ubuntu the image is simply removed from the document. The image is not linked, but inserted. I can reproduce this on demand. Originally found in: Ubuntu: LibreOffice 3.3.2 OOO330m19 (Build:202) tag libreoffice-3.3.2.2, Ubuntu package 1:3.3.2-1ubuntu2~lucid1 and Windows: 3.3.4 The EMF graphic was created by SmartDraw VP in Windows and is a network toplogy diagram, not a chart. I use Linux or Windows interchangably and OpenOffice didn't seem to suffer from this difference in EMF file handling. I've tried Ubuntu 3.4.4 and still see a garbled EMF diagram. If I edit the document only on a Windows LibreOffice the EMF diagram is not mangled. If I import the same EMF diagram into Linux LibreOffice I see the same mangling.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
3.5 beta 1 completely fails to parse the emf image and displays it as text within the document. This is a serious regression since version 3.5 would display an image, even though not correctly.
Created attachment 56579 [details] Super/sub script example Other EMF import bugs (3.5.0 rc1, Windows XP): super/subscript is mangled when the EMF is reduced to objects with modify->break. On initial import of EMF it looks OK, things only go wrong when the EMF is converted to LO objects.
Created attachment 56580 [details] Wide lines drawn as narrow, rotated text misplaced Other EMF import bugs (3.5.0rc1 Windows XP) 1. On EMF input of this example several of the wide lines are drawn very narrow, probably one pixel wide. Internally they show a width of zero. This happens, for instance, with the 72pt and 36pt lines, but not the 144pt (180px) line. 2. On modify->break rotated text is offset from the correct position. Note, this example was designed for testomg EMF insertion into PPT2003. To get the right text sizes first set the LODraw page size to 10.84" x 7.5", margins all zero. Import the EMF, then stretch to fit the page. Modify->break. Font sizes will then be as marked in the example. On Windows use "preview" to see what this EMF should look like.
Radek - a set of EMF rendering issues, any ideas ? :-)
Regression does appear in oldest version of bibisect-3.5.tar.lzma and must be older.
not a Writer bug, we don't seem to have a GSL or VCL or even framework component (but a PDF export ?), so Libreoffice it is...
Additionally this seems to be an RTF regression as well, lacking the support for the \bin keyword.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5187174cd4054486100ef29125ee4a36f7e3bee3 fdo#39053 writerfilter: implement RTF_BIN
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=385017e0f2147d2a49e36d6c44ae76a1e7600668 testcase for fdo#39053
Removing rtf_filter from whiteboard, the RTF filter now reads the EMF data correctly, the rest is independent from RTF. :-)
Created attachment 60409 [details] EMF extracted from RTF.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ed5010f24fc3992945f72225e3d7d1351f048404&g=libreoffice-3-5 fdo#39053 writerfilter: implement RTF_BIN It will be available in LibreOffice 3.5.4.
clearing target flags as that is only for the 3.5 RTF \bin import, while the original problem remains; Miklos should have filed a separate bug for that really...
This issue still exists in 3.6. The gradient and text are drawn correctly now, but the borders aren't drawn at all.
*** Bug 35986 has been marked as a duplicate of this bug. ***
EN: In LibreOffice 4.4.0.3 it is fixed. Please ckeck and close bug RU: В LibreOffice 4.4.0.3 это исправлено. Пожалуйста проверьте и закройте заявку
(In reply to seven from comment #23) > EN: In LibreOffice 4.4.0.3 it is fixed. Please check and close bug Not fixed. LO 5.0 opens the original attachment 48870 [details] the same as in the comment. (In reply to Alistair Leslie-Hughes from comment #21) > The borders aren't drawn at all.
*** Bug 91636 has been marked as a duplicate of this bug. ***
Created attachment 117162 [details] Comprehensive EMF test case, most recent version For those of you working on EMF support, here is my most recent test file, which exercises most of the features of that file type.
Migrating Whiteboard tags to Keywords: (preBibisect) [NinjaEdit]
In current master, the graphic is visible but shadows and some borders are missing. Best regards. JBF
Not sure if this bug report still must be seen as a regression. Indeed regression keyword has been added for version 3.5 beta 1 that did not display the image at all. This problem has been fixed and we are back to the original bug description. --> removing regression keyword. Best regards. JBF
Only regressions should use the keyword 'preBibisect'. Removing it...
What kind of EMF editor are you using?
(In reply to Bartosz from comment #32) > What kind of EMF editor are you using? Was that directed at me? The test files I post are from libUEMF https://sourceforge.net/projects/libuemf/ That library is used by inkscape for importing/exporting EMF/WMF on all platforms. So to the extent I use an "EMF editor" it is Inkscape. For debugging EMF files there is a text dump program in libUEMF which works everywhere. For Windows platforms one can also use Joseph Newcomer's excellent "MetafileExplorer" program.
Review is available at: https://gerrit.libreoffice.org/36261
Review which fix this issue is available at: https://gerrit.libreoffice.org/#/c/36317/