At least PARTLY REPRODUCIBLE with LibreOffice 3.5.4.2, German UI, on MacOS X 10.6.8 German.

This is a very interesting issue. I have tried to reproduce it, but the results are complicated.

1) I have tried to save your .odt sample file "SVG-Doc-Bug.odt" as .doc file and .docx file myself. I can confirm that the SVG diagram becomes a bitmap image, therefore REPRODUCIBLE (and set Status > NEW). However, the resolution of the bitmap is a bit better than in your sample .doc file. Therefore, there seems to be some circumstances which have influence on the resolution of the bitmap generated. This is (at least) interesting.

2) I have created some simple .odt sample files which contain some SVG graphics. At least in one case, if I save the .odt file as .doc or .docx file, the .doc and .docx file seem to contain the original vector graphics -- at least, I can scale the .doc and .docx files without any visible loss of quality.

3) In some other cases, if I save the .odt file as .doc or .docx file, the .doc and .docx file contain just bitmap images, just like in the original sample file.

So, this seems to be a complicated issue: in some cases, LibreOffice Writer seems to embed the vector graphics in the .doc/.docx files, in the other cases it just exports a bitmap image to .doc/.docx, and even the resolution of this bitmap image seems to differ in quality.

I will attach sample files for all three cases.

Created attachment 63571 [details]
Comment 1 case 1: Bernd's .odt sample file saved as .doc file, resolution of bitmap seems better

Created attachment 63572 [details]
Comment 1 case 2: .odt file with SVG graphics which seems (!) to get saved as vector graphics to .doc/.docx

Created attachment 63574 [details]
Comment 1 case 3: .odt file with SVG graphics which becomes bitmap in .doc/.docx

Could this be related to Bug 49832 - "PRINTING: Writer rasterizes SVG for output to a printer or into PDF, which leads to poor quality laser printing"? Just an idea ...

Changing Component to "Printing and PDF export", as appropriate

LO 3.5/3.6 stores vector graphics as SVG internally, but every output is done via bitmaps. As Roman says, this is related to Bug 42092. (By the way, attachment 42092 [details], "RNE sample 1, B+W floor plan.zip", also contains only a bitmap, but hi-res.) Word cannot handle SVG, so vector graphics have to be converted to EPS or a WMF format. LO doesn't do that, even the current LO 4.0.0 alpha: it still rasterizes SVG for DOCX output.

Changed component and platform. I think this will be the same on every system.

can you test if that problem still happens on 4.0, which has
a different SVG implementation?

Created attachment 80523 [details]
Collection of screenshots (PNG) showing visual output quality.

This bug appears to have two distinct parts. The first (a) appears to be the degradation ("low-resolution pixel graphics"), of a SVG embedded in an ODT file, when the file is saved in DOC/DOCX format. The second (b) seems to be the conversion, of a SVG embedded in an ODT file, to a raster format (e.g., PNG) when the file is saved in DOC/DOCX format. Comment #7 (and related comments in bug #42092) would seem to indicate that this second part is probably unavoidable and thus not a valid consideration for this bug. Microsoft would certainly prefer people use Silverlight in preference to SVG.

This leaves (a) which I think can now be RESOLVED as FIXED. I have tested all the attachments to this bug under Crunchbang 11 running TDF/LO v4.0.3.3 (Build ID: 0eaa50a932c8f2199a615e1eb30f7ac74279539) and there is marked improvement in the on screen display for the examples and indiscernable graphic output quality to PDF. This would appear in keeping with the remark in bug #42092#c45. There is however a difference in the nature of some of the attached SVGs that needs to be described. I will refer to the initial attachment as "BS_orig" and the other three attachments as "RME_c1_orig", "RME_c2_orig", and "RME_c3_BS_orig". Each SVG was generated by:

BS_orig = graphviz version 2.28.0.
RME_c1_orig = Inkscape.
RME_c2_orig = Adobe Illustrator 13.0.2, SVG Export Plug-In . SVG Version: 6.00 Build 14948.
RME_c3_BS_orig is simply the ODT from BS_orig resaved as a DOC.

Not all SVGs are equal and SVGs exported from Draw can behave differently again to these examples. This is not an issue for this bug but rather a consideration that must be taken into account when testing with these file formats. It is worth noting that the text in the BS_orig SVG appears formatted differently in some of my tests probably because I do not have the Helvetica Type 1 font installed. The difference described in comment #1 (point 2) and comment #3 is due to the original SVG being converted to an EMF in the DOCX (and probably DOC). The reason for this (under v3.5/3.6) is indicated in comment #7 and in several comments in bug #42092 relating to EPS handling. This is no longer the case under LO v4.0. All ODT files from BS_orig, RME_c1_orig, and RME_c2_orig, when resaved as DOCX include only a PNG.

I have attached a collection of images showing the on screen quality for the various examples and how each ODT/SVG appears when re-saved as DOC/DOCX/PNG. All are taken at 100% zoom with anti-aliasing turn on. The file names should be indicative.

Might this bug be a duplicate of bug #68927? Then this one might already be fixed.