Apache OpenOffice (AOO) Bugzilla – Issue 82873
Linked OO Draw objects broken, view/zoom depends on last view from OO Draw
Last modified: 2014-02-12 06:14:58 UTC
Embedding objects from OO Draw is not working really. When you embed an object from a file, the view on the drawing is based on how the drawing was viewed the last time with OO Draw. This is not acceptable, and therefore, it is completly beyond my understanding, how an issue 38965 like can be disabled intentionally. When you insert a drawing into writer as an OLE Object, the zoom level is what was used the last time the drawing was edited in OO Draw. The only way to modify how the drawing appears in OO Writer is to configure how it is displayed in OO Draw. Bad luck if you have not linked the objects, then you have no possibility at all to scale the drawing to match the formatting of your text. Is this really how it's meant to be? What is missing, is in my opinion: 1) The possibility to define a scale for all objects, drawings in OO Writer, so that you can downscale embedded drawings and other objects 2) If you copy&paste a page from OO Draw to OO Writer * From the main view: pasted are all selected elements (all all elements on that page, if no selection was made), much like you would export to StarView Metafile or Windows Metafile first, and then import that picture. * From pages sidebar: paste the complete page, not just a group of the drawings. In Writer the frame of the object should be identical with the page borders. 3) Make the display in OO Writer independent of the display in other applications
Drawing issue.
Thanks for moving it to the correct component. Since it's now not directly connected to Writer in the summary or beginning of the description, I would like to make clear again, that this issue is about: Embedding OO Draw objects in OO Writer. Possibly this also applies to other OO Applications, but I have not tried that.
According to an internal issue this is a feature and not a Defect.
I disagree that this is a feature and not a defect. From a user-perspective, this is definitly a bug. Could you please explain why the internal issue is reasoning that this is a feature?
I am also interested in this. I am going to try to file a bug report to improve writer behavior. Maybe things will get better this time.
This same bug has been reported many times. 16156: Aug 2003, OO 1.1 20643: Oct 2003, OO 1.1 28046: Apr 2004 50398: Jun 2005, OO 2.0 beta 53266: Aug 2005, 680m122 72879: Dec 2006, OO 2.1 73343: Jan 2007, OO 2.1 81143: Aug 2007, OO 2.2.1 82873: Oct 2007, OO 2.3 93426: Sep 2008, OO 2.4.1 and OOO300m4 If the author of this Issue is still online, please consider the contents of 16156 and 93426. If the solution addresses your issue, please vote 2 for 16156.
sI currently use "Ooo 3.1.0 WIN XP multilingual version German UI activated [OOO310m11 (Build 9399)]" and can confirm the reported ugly effect, what makes the feature "Linked Ole Objects" completely unusable. So I believe, that this is the DEFECT and not a FEATURE. What should linked objects be useful for, if view in documents where they are linked always will be destroyed after the object has been edited? A linked object view must always show the same partial view of the OLE object! I created a test kit to demonstrate how this DEFECT makes linked OLE objects feature unusable for "real world work". Steps to reproduce: 1. Unpack test ket and open "text.odt". It sould look as you see in "SoShouldItLook.pdf" 2. close "text.odt" 3. open "oleobject.odg" for a little Edit 4. Draw a nose into the smiley as you see in "SoDoesItLook.pdf" 5. Change WINDOWS window to "max size" 6. save and colse "oleobject.odg" 7. reopen "text.odt" expected: everything unchanged, only smiley now shown with nose actual: smiley nose completely destroyed as you see in "SoDoesItLook.pdf" The problem is not limited to DRAW, you see a similar problem if you open "spreadsheet.ods", resize window to max and add some rows "a10" ... "a16" Expected: View in "text.odt" should not be modified, new lines remain invisible Actual: As you see in "SoDoesItLook.pdf" It would be interesting to see how that works with OLE objects from other applications in OOo. May be, this is not an OOo problem but a problem with ISO specification?
Created attachment 63272 [details] Test kit for 'comments from rainerbielefeld Mon Jun 29'
Might be related to Issue 64202
Modified Subject. An other ugly effect related to the reported problems, pls. see attached "AnOtherUglyEffect.odp"!
Created attachment 63283 [details] Demonstraton of an other ugly effect
I see the same problem with linked WRITER OLE objects in DRAWING documents. Because of the unpredictable view after modifications in the WRITER documents this feature is completely useless. May be someone wants to vote for this issue?
This is more or less the same as Issue 81143. May be some day someone will merge and handle all these "view with last edit zoom" issues?
Still Reproducible with server installation of "AOO 4.1.0-Dev – English UI / German locale - [AOO410m1(Build:9750) - Rev. 1565724 - 2014-02-09]" on German WIN7 Home Premium (64bit)", own separate user profile.