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. ***