Problem description: When a document with a fontwork is opened the "fontwork" is missing. Steps to reproduce: 1. ....Create a new document with a fontwork 2. ....Save the file and close it 3. ....Open the file, the fontwork is missing Current behavior: Fontwork disappears Expected behavior: Fontwork doesn't disappear Operating System: Ubuntu Version: 4.0.0.3 release
The same problem happens on win7 64 bits and Ubuntu 12.10 64 bits
(In reply to comment #0) > Problem description: When a document with a fontwork is opened the > "fontwork" is missing. > > Steps to reproduce: > 1. ....Create a new document with a fontwork > 2. ....Save the file and close it > 3. ....Open the file, the fontwork is missing > > Current behavior: Fontwork disappears > > Expected behavior: Fontwork doesn't disappear > > > Operating System: Ubuntu > Version: 4.0.0.3 release
Thank you for reporthing this bug, I can reporduce this bug running LibreOffice 4.0.0.3 on Windows 7.
*** Bug 60966 has been marked as a duplicate of this bug. ***
I can confirm this behavior using LibreOffice Version 4.1.0.0.alpha0+ (Build ID: c16e9f4ed97f65357e9986f46ad88ee9f223799) with Linux Mint 14 x64.
I confirm that the issue is the same on newer LO 4.0.1.2 release, compiled on Gentoo amd64.
Returning to binary package version 3.6.4.3 for Gentoo, and the same document, without problems. The fontwork is saved and restored ok.
*** Bug 62285 has been marked as a duplicate of this bug. ***
Version 4.0.1.2 (Build ID: 400m0(Build:2)) save as .odt and fontwork disappears save as .docx and fontwork disappears BUT save as .doc and fontwork is still there... at least for me.
Confirmed what is in comment 7, so it's a regression.
So it turns out the 4-0 branch-off was still OK; however latest 4-0 doesn't export the shape. Bisect says: 75118d2f9ebdf96250d3a4c78b695085c3527e4e is the first bad commit commit 75118d2f9ebdf96250d3a4c78b695085c3527e4e Author: David Tardon <dtardon@redhat.com> Date: Tue Dec 18 15:24:28 2012 +0100 fdo#56267, fdo#56980 propagate shape change to subclasses It turns out (as witnessed by fdo#56267) that my fix for fdo#56980 only cured the symptom, not the cause. The real problem is caused by the following sequence of events during ODF import: 1) an SvxCustomShape object is created (XShape iface) 2) an SdrObjCustomShape object is created for the SvxCustomShape, but it is not associated with it (yet) 3) another SvxCustomShape object is created internally by the SdrObjCustomShape and they are associated 4) an EnhancedCustomShapeEngine is created for this SvxCustomShape by SdrObjCustomShape 5) the SvxCustomShape from point 1 is set to the SdrObjCustomShape At some point (I did not follow this explicitly) the SvxCustomShape cached by the EnhancedCustomShapeEngine loses its (weak) reference to the SdrObjCustomShape. This leaves it gutted and all subsequent calls to render() return an empty XShape. The solution is simple: let SdrObjCustomShape know that the associated UNO shape has changed, so it can drop the custom shape engine. Change-Id: I267838ea4857dfcd646f40c811f3ae572237a1e6 (cherry picked from commit 7fec8dfcaca4efc92516f9af51a3157f1a11ccd7) David, sorry to hear, it seems we have one more commit in this never-ending game. ;-(
In 4.0.2 release this bug is still present. (Please fix it because for schools and children this function is very important)
We are also a school and it's a pretty bad bug for us as well M
@all: May I remind you to keep Summaries up to date? It's a little difference whether the object becomes lost during filesave and fileopen, and queries for DUPs are more promising if the summaries are correct.
*** Bug 63686 has been marked as a duplicate of this bug. ***
*** Bug 62320 has been marked as a duplicate of this bug. ***
Created attachment 78406 [details] oval.doc This bug also affects .doc files containing shapes 1. Open the attached oval.doc and admire the shape (a blue oval) 2. Save as oval.odt and close it 3. Open oval.odt and the blue oval is missing This appears to be a symptom of the same bug because it is solved by reverting 75118d2f9ebdf96250d3a4c78b695085c3527e4e. As per comment 9, saving as .doc is not affected by the issue. I tested in 4.0.2.2 and git master.
Luke Deller committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=15bbafaaed52182e80f1a24d716a2d181cdc0e17 fix fdo#60910 FILESAVE loses fontwork/shape objects The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This problem occurs because: - SdrObject::getUnoShape() constructs a UNO shape object using the associated page object (SdrObject::pPage) - Shapes in Writer use page object of class SwXDrawPage which creats UNO shape objects with the class SwXShape, which implements both XShape and XTextContent interfaces - In this bug, SdrObject::getUnoShape() is called earlier than SdrObject::SetPage(), so the UNO shape object is created with the class SvxShape which does not implement the XTextContent interface, so it is skipped when outputting the odt text document I think the proper solution is to invalidate the cached UNO shape object in SdrObject::SetPage Regarding the line in SdrObjCustomShape::InvalidateRenderGeometry to set mxCustomShapeEngine = 0L: - added by David in commit 76350361f386b78e1bc9edb75af89e7ff3afe356 which introduced crash bug fdo#58267 - removed by David in commit 75118d2f9ebdf96250d3a4c78b695085c3527e4e which introduced the bug in this item (fdo#60910) - readded by my own commit for this item - no longer causes the crash analysed in fdo#58267 due to David's commit 31b93b8600a3e219d33173aa68d9ab570e477e50 This line prevents the present bug because the custom shape engine is the only object holding a strong reference to the UNO shape object, so when it is destroyed the UNO shape object will be destroyed too. I am going to submit another patch to remove this line again as it invalidates the shape more often than needed, in favour of a change to clear the UNO shape when SdrObject::SetPage is called.
(In reply to comment #19) > This problem occurs because: > - SdrObject::getUnoShape() constructs a UNO shape object using the > associated page object (SdrObject::pPage) > - Shapes in Writer use page object of class SwXDrawPage which creats UNO > shape objects with the class SwXShape, which implements both XShape and > XTextContent interfaces > - In this bug, SdrObject::getUnoShape() is called earlier than > SdrObject::SetPage(), so the UNO shape object is created with the class > SvxShape which does not implement the XTextContent interface, so it is > skipped when outputting the odt text document Right. That is where I got with my analysis too. > > I think the proper solution is to invalidate the cached UNO shape object in > SdrObject::SetPage This indeed sounds like it should work. It can still cause more invalidating than necessary (e.g., when moving an object to another page in the same document, or when copying an object to a different document of the same type), but I do not think that matters much.
Luke Deller committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=57082b1243e86694b72c5e4fad013bf207bfe81a fdo#60910: discard UNO shape object in SdrObject::SetPage The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Luke Deller committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=879c36b01d3f806937cfc26b90ebac89e6df87c4&h=libreoffice-4-0 fdo#60910: discard UNO shape object in SdrObject::SetPage It will be available in LibreOffice 4.0.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I can verify this is fixed in current master version (Mac OSX 10.8.3) LibreOffice Version: 4.1.0.0.alpha0+ Build ID: 1cd9b5d859a6468164b043b0fcaaf49c1907500 (=master~2013-04-29_05.54.57_LibreOfficeDev_4.1.0.0.alpha0_MacOS_x86-64.dmg) Thanks! Joren
*** Bug 64134 has been marked as a duplicate of this bug. ***
Is there any chance of getting this into 4.0.3 ? Ta M
(In reply to comment #25) > Is there any chance of getting this into 4.0.3 ? No.
*** Bug 65476 has been marked as a duplicate of this bug. ***
*** Bug 70320 has been marked as a duplicate of this bug. ***
*** Bug 67066 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.