Apache OpenOffice (AOO) Bugzilla – Issue 68300
bogus scaling / size on load ...
Last modified: 2013-08-07 15:20:06 UTC
So - the OLE object (perhaps just the preview?) is rendered at the wrong size here - the text is tiny. Of course MSO renders it nicely, but interestingly if you in-place activate the object, and save again - MSO appears to 'correct' the file too (somehow) - hiding the issue. Any hints on where to dig in the code ? do you have tools to split out the WMF preview to see if it's at fault ?
Created attachment 38374 [details] question ? :-)
Reproducible. Reassigned.
Created attachment 38558 [details] added the extracted graphic
accepted
looking at the problem, it looks like the wrong size comes from client anchor in SvxMSDffManager::ImportShape. it can be corrected in impress by using "Original Size" item from popup menu. sj, does it ring a bell? is there any documentation where I can read about child/client anchor and ole object size handling?
After looking a bit closer to the problem I found out that we do not have a problem with client/child anchors, instead the problem is that we do not support cropped OLE objects.
Indeed, looks like it. I played with it in MS office and the anchor (bounding box?) looks OK - it has the same size. In MSO the anchor rectangle is used as bounding box for the rendering of embedded object. Once you edit the object it behaves weird as it rescales the embedded object to the anchor rectangle and keeps it that way. Interestingly enough when saved and loaded again, it uses it as bounding box until edited again. So before the rendered output before saved and after save/load looks differently. Not sure why it behaves that way, I guess it might be an incompatibility between various MSO versions? I will look more into the embedded object code. It takes me ages though as I don't know much that code yet. I am also completely unaware about OLE objects. Any hint where I can read about embedded OLE objects and how they are stored in streams/on disk?
What I described happening in MSO might be the same MSO problem as this one: http://support.microsoft.com/kb/165723 (just the opposite direction: embedding word in ppt)
sj->radek: If you want to know something about the ole code, you should ask mav, he was responsible for the new ole implementation which can be found in embedserv & embeddedobj.
Created attachment 40567 [details] proposed patch
I have a patch which crops ms ole objects. Not sure yet though whether we should crop always or not.
sj->radek: I just tested your patch, it works good for the attached bugdoc, but it does not work for most other cropped OLE objects. Another sideeffect is that you can't scale OLE objects any longer. Due to this reasons I suggest not to integrate your patch. I think the OLE object must be able enabled to store additional cropping data, therefore we have to enhance the file format, it is the same we have in Issue 67705.
sj: could you please attach some other examples where it doesn't work? Do you know how to say whether OLE object is cropped or not?
sj->radek: sorry for the long delay, but I was very busy the last days. Cropping is a drawing shape feature and is not supported by OLE objects, so if a OLE object is cropped is determined by following properties of the OLE shapes msofbtOPT atom: Prop_cropFromTop Prop_cropFromBottom Prop_cropFromLeft Prop_cropFromRight I added a example that is not working properly when applying the VisualAreaSize of the OLE object as it is done in your patch. So the general question exists further on, and as long as nobody knows for sure when to use the VisualAreaSize scaling, it seems to be better not to use this size.
Created attachment 40659 [details] cropped ole object that is not working properly when using the VisualAreaSize
In my opinion the problem has to do with the replacement graphic. It's an WMF file which is treaten different in PP and Impress when scaling is applied. Had a short chat with thb about that and he beleives that its a "misfeature" in PP. The problem here is that the WMF (attached as dbggfx0.wmf) is interpreted differently by various tools. E.g. the "windows picture and fax viewer" displays a width of 406pixel and a height of 1011 pixel. However e.g. the "Microsoft Picture Manager" displays a width of 1680pixel and a height of 1050 pixel. OOo seems to take the 1680x1050 size whereas PP takes the 406x1011 size for display. I believe this is why scaling is different. So --- I haven't yet figured out where the different values come from. sj => Do you have a suggestion where the different values could come from?
changing issue type back to defect as no working patch is available
set target from 2.x to 3.x according to http://wiki.services.openoffice.org/wiki/Target_3x