Created attachment 950 [details]
The orignal .jpg graphic, size 169KB

Created attachment 951 [details]
File created by MS Word

Created attachment 952 [details]
The file opened by oo then save as .doc again

Reassigned.

MRU->CMC: When we import a Word document with a graphic and then
re-save it as .doc, the size increases. Isn´t it possible for us to
keep the original format of the graphic when we first import and then
again export such a doc?
BTW: the file size increase about ten times, not hundreds... ;-)

just to emphasize the problem
(excuse only, i really do a wrong calculation... ;-)

But this sounds for me like a problem of the MS esher import/export. 
And I think we have the same problem in the Excel and PowerPoint 
filter.
For esher imp./export is SJ responsible, so I assign this issue to 
him. If it is wrong, I'm sorry.

The escher import/export is working correct. If I load the word 
document and paste the graphic into Impress or Calc and save it to 
then the corresponding Microsoft format, the original jpeg version of 
of the bitmap is used, and the size of the new document is passable, 
whereas if I save the document to Word the escher export 
implementation in svx is not used. It seems that there is a special 
treatment in the Writer and so Juergen might be the right contact for 
this problem.

JP->CMC: then please have a look to it

Yes, this graphic is an inline graphic. i.e. anchored as character, or
a 0x01 graphic.

"True" escher graphics are those that are not inline, the otherwise
anchored graphics (i.e. 0x08 graphics). Inline graphics are stored by
word in the older preescher mechanism. In older versions of word these
are metafiles and therefore big. In newer versions of word these
inline graphics can be stored as basically "fake" escher graphics.
i.e. in escher format but outside and seperate from the normal escher
graphics pool. 

The problem was that in the past we only imported these graphics
through something of a hack (WW8QuickHackForMSDFF_DirectBLIPImport).
There are one or two differences from these "fake" escher graphics
than those found normally in the pool. I was able to fold most of the
two graphic importing mechanisms together for importing
(cvs diff -r1.5 -r1.6 ww8graf2.cxx), but our export for inline
graphics continues to use the 0x01 mechanism with no eschers and
metafiles instead, which is the same for 97+ as well as 95-. 

It would be possible to export these inline graphics as these "fake"
escher ones, but there are a few unknowns in the header which would
have to be understood before doing so. One or two things that we can
ignore and skip on importing, but are likely vital for export to work.
And our escher exporter is also likely to have to be reworked to write
graphics outside the normal graphic pool. Basically how word is
creating these escher type compressed graphics outside the escher pool
is itself a hack that we would have to duplicate.
For what its worth this should only affect graphics anchored as
character, other types of anchoring shouldn't show such dramatic size
increase through being converted to metafiles on export. And documents
created like this work perfectly ok except for the size increase. I'll
look into it closer to see if we would be able to fix it.

Implementation needed, but not going to happen very soon.

*** Issue 7172 has been marked as a duplicate of this issue. ***

Have now implemented this technique for export of inline graphics. 

Results:
.doc original:          194,560 bytes
OOo output .doc:        182,784 bytes

So that's the kind of result we want to see :-)

Be a while until this makes a build, mark as started until that time.

This improvement is in place for SRX643z

*** Issue 6833 has been marked as a duplicate of this issue. ***

MRU: Yes, works fine with this version. will be available for
OpenOffice in release 643.

*** Issue 7428 has been marked as a duplicate of this issue. ***

test in developer version 643, this bug is not fixed yet

Yes, that's right. But the fix is noiw definitly in newer build
OpenOffice 643C.