Issue 2179 - Creation of OlePres000 stream in embedded object...
Summary: Creation of OlePres000 stream in embedded object...
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: current
Hardware: PC All
: P3 Trivial (vote)
Target Milestone: OOo 1.1 Beta
Assignee: michael.ruess
QA Contact: Unknown
Depends on:
Blocks: 1997
  Show dependency tree
Reported: 2001-11-12 13:36 UTC by caolanm
Modified: 2003-01-17 14:00 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description caolanm 2001-11-12 13:36:05 UTC
In issue 1997 there is a word document with an embedded object which originally
contains no OlePres000 stream, on importing and exporting one is created. Can
you tell me what this stream is for ?. Is it a preview image ? If so is it
necessary, this object already contains a preview image in its META and PIC
streams, and the creation of an OlePres stream inflates the original size of the
document by a sizeable 93k. I believe that this stream is created in the so3 module.

In an ideal world I would like the exported object to be the same size as the
imported one, to avoid accusations that our winword filter increases the size of
imported word documents. The only element that increases in size from the
original document in 650 is now the embedded object. To see the extra stream
import and export document attached to issue 1997.
Comment 1 kay.ramme 2001-12-21 14:28:22 UTC
Matthias, seems to be yours?
Comment 2 Mathias_Bauer 2002-01-07 09:22:05 UTC
This is a problem of the winword import/export.
Comment 3 jp 2002-01-08 18:38:38 UTC
JP->MBA: that isn't correct so, because the stream is created with the 
following call stack. And this shows that the SvEmbeddedObject creates 
this stream. The great question now is, why?

Impl_OlePres::Write(SvStream & {...}) line 224
WriteExtContent(SvStream & {...}, const GDIMetaFile & {Anzahl=194}, 
unsigned short 0x0001, unsigned long 0x00000002) line 598
SvEmbeddedObject::MakeContentStream(SotStorage * 0x078819d8 {Cnt=1}, 
const GDIMetaFile & {Anzahl=194}) line 622 + 17 bytes
SvEmbeddedObject::MakeContentStream(SvStorage * 0x078819d8 {Cnt=1}, 
const GDIMetaFile & {Anzahl=194}) line 630 + 13 bytes
DL641MI! SvxMSDffManager::CreateSdrOLEFromStorage(class String const 
&,class SvStorageRef &,class SvStorageRef &,class Graphic const 
&,class Rectangle const &,class SvStream *,unsigned long) + 2216 bytes
SW641MI! SwWW8ImplReader::ImportOleBase(class Graphic &,unsigned 
char,class Graphic const *,class SfxItemSet const *) + 1354 bytes
Comment 4 Mathias_Bauer 2002-01-23 17:03:37 UTC
Currently I have no idea, because I lack information about OLE streams
used for preview purposes. I'm not convinced that this is a bug,
because it may be that the other streams mentioned are private MS
stuff, the only documented stream I no is the OlePres stream. I will
investigate this.
Comment 5 lsuarezpotts 2002-02-07 03:28:34 UTC
Reassigning to UDK, as OI is closed
Comment 6 caolanm 2002-07-08 17:19:12 UTC
For the record in writer we're deleting the \2OlePres000 on export
from SRX643k onwards.
Comment 7 Mathias_Bauer 2002-07-09 08:14:04 UTC

As it turned out the reason for this stream is the following:
inside the word document it exists inside the container. Our file 
format is not OLE storage based, so we store it inside the OLE 
object. As long as we don't store them back into MS formats, there 
shouldn't be a problem, and as it seems, the problem will also be 
fixed for MS formats.

Another problem may be that MS stores this stream in a compressed 
mode, OOo does not. But this has also been fixed for the 643 build.

I will ask the calc and draw/impress filter developers to do the same 
fix as Caolan did for the writer (delete presentation stream on 
export), and then IMHO this bug should be fixed.
Comment 8 caolanm 2002-07-09 09:28:21 UTC
#99809# is the internal "delete the stream" id. 
Comment 9 Mathias_Bauer 2003-01-08 10:36:59 UTC
Fixed in all builds >=644.
Comment 10 Mathias_Bauer 2003-01-17 13:34:14 UTC
Comment 11 Mathias_Bauer 2003-01-17 13:34:29 UTC
Michael, please verify this fix in the corresponding builds.
Comment 12 michael.ruess 2003-01-17 14:00:08 UTC
Tested with internal build. Fix looks good.
Comment 13 michael.ruess 2003-01-17 14:00:51 UTC
Fix will be public in openOffice 1.1 Beta