Apache OpenOffice (AOO) Bugzilla – Issue 102707
Big repaint problem with Writer-OLE document containing a frame
Last modified: 2017-05-20 10:30:52 UTC
Trying to integrate a Writer document via OLE into another OO document (e.g. Writer or Draw - doesn't really matter, it's the same trouble) works just fine as long as the document to be integrated does not contain any images or frames. I gues it will probably be the same with any "free positioning element". The output looks somehow as if the image or frame is anchored in the integrating document. Howver - the whole integrating document will be more or less mixed up afterwards.
Not a P2. Please attach a sample document and screenshots showing the problem.
Created attachment 62950 [details] ZIP containing the sample documents and a screen shot
Description: - new Writer doc with some text (I will attach a file "Container.odt") - another Writer doc with some text and a text frame (I will attach a file "OLE_with_frame.odt") - Insert the second document ("OLE_with_frame.odt") as OLE iinto the first document ("Container.odt") -> the text frame of the OLE object is floating outside of the OLE (I'll attach a screen shot)
Created attachment 63197 [details] Container.odt
Created attachment 63198 [details] OLE_with_frame.odt
Created attachment 63199 [details] floating_outside.JPG
Regression. Broken since 3.1.
OD->SJ: Please have a look (may be also AW). Embedded Writer documents with a Writer text frame are not displayed correct in any application (Writer, Calc, etc.). It look like as if the generation of the replacement graphic does not work: - Creation of the replacement graphic for Powerpoint export with activated conversion works fine. - Opening such a document in OOo 3.0 also shows the wrong display, but an activating-deactivating-cycle corrects the display.
changed target
The problem only occurs with writer objects, so this is most probably a writer/aw problem. As we found out, the metafile recording of these objects is correct (pdf export), so it might be the primitive wrapper from aw. sj->od: As discussed you get this issue back.
AW: This is probably double to #i98753# where the same effect occurs. AW: I disagree. The size of OLE is set in the DataTransferObject for it, not sure where this is or what the class is named exactly, but that size is calculated somewhere in SW and used for that transfer data object. Maybe it gets somehow lost. One thing that comes to mind is the change of transfer formats from internal stuff (like MetaFiles) to ODF, done by TL, thus setting to CC. AW->TL: May those changes have changed the sizes for OLE transfer and thus have caused the regressions #i102707# and #i98753# ?
TL: As mentioned in the other issues as well: the change of the clipboard format is not yet completed. That cws (tl77) is on hold since no one currently has the time to look into the resulting convwatch issues. Thus nothing has changed yet in that respect.
fixed in cws os151 - changed file: /sw/source/core/draw/dflyobj.cxx, change set http://hg.services.openoffice.org/cws/os151/rev/99f126ca6231
fix reviewed by OS
od->mru: Checked in internal installation set of cws os151 - please verify.
Verified in CWS os151.