Created attachment 53215 [details] ODP file with a CC logo in the slide master Problem description: the problem occurs, for me, only with the master I compiled myself Steps to reproduce: 1. open the following RTF file: https://bugs.freedesktop.org/attachment.cgi?id=52627 2. close this RTF file without exiting LibO 3. open the attached odp file Current behavior: in the lower left corner you see the French Republic logo Expected behavior: in the lower left corner you see the Creative Common logo as you see if you reload the odp file (File > Reload) Platform (if different from the browser): Browser: Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111105 Firefox/10.0a1
I reproduced it on MacOSX with master at core:59829f4fd20f4238941123412423caa76e8be1a6 If I delete the temp files in the temp directory of LibreOffice and then re-open the odp, I get the correct graphic.
I confirm on linux with master on Ubuntu 11.10.
No problem if I convert the RTF file to ODF format and play the same scenario with this new file instead of the RTF file. Best regards. JBF
This should fix it: http://cgit.freedesktop.org/libreoffice/core/commit/?id=009c572b2f058b80d2427c775d821c632491c869
I confirm that this commit solves the problem. Thank you for this quick fix. Closing the bug report. Best regards. JBF
Sorry Miklos, if you don't close the RTF file before opening the ODP file, you see the wrong logo too. :-( Best regards. JBF
Created attachment 53224 [details] Same problem with this file
Same problem using the ODT file instead of the presentation.
There is an error message with --enable-debug : Error: File /home/arnaud/core/sal/osl/all/debugbase.cxx, Line 125: unexpected number of 19SvxUnoTextRangeBase: 1
[Reproducible] with parallel installation of MinGW Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: 2ba5d12-e8c71c5-41e7bcd-4b83b90)] (daily/MinGW_cross-compilation2011-10-25_00.12.09)". [Reproducible] with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: d3d1481-3f8994a-2ba0a9f)]" (110909) With both versions I only can open modele_dec_he_so.rtf one times. When I have closed it without leaving LibO, I can't open it a second time (from LibO file dialog), but I will get an error message: Document file 'modele_dec_he_so.rtf' is locked for editing by: Unknown User Open document read-only or open a copy of the document for editing What ever that might mean concerning the reported problem.
Rainer, That part is a feature, not a bug. :)
@Miklos Vajna: No feature (I have a little experience with LibO)! May be my wording was misinterpretative? Steps to reproduce with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: d3d1481-3f8994a-2ba0a9f)]" (110909) 1. Start soffice.exe 2. Open "modele_dec_he_so.rtf" from start center As expected it opens, ".~lock.modele_dec_he_so.rtf#" appears in document folder 3. Menu 'File -> Close' As expected document opens, lockfile disappears 4. Menu 'File -> Open - "modele_dec_he_so.rtf" Expected: can be opened Closed: Message as described. The document remains locked, also can not be opened with another instance of LibO (3.4.4 RC2) until Libo Master will have been terminated.
Rainer, Ah OK that is indeed a bug - I was not aware you closed the document between the two openings. ;) Thanks.
I'll take this for a while, started looking at it in any case, if I get nowhere I guess I'll put it back to the list.
proposed fix here http://cgit.freedesktop.org/libreoffice/core/commit/?id=02c6f5c74b346f1e3a095d99a36ece6b603bc26b problem stemmed from the fact that properties were getting set before sdr object is created, this resulted in SvxItemPropertySet::AddUsrAnyForID getting called. see http://opengrok.libreoffice.org/xref/core/svx/source/unodraw/unoshape.cxx#1807 Since the SvxItemPropertySet is shared between SvxShape instances the next opening detects these strange 'OwnUsrAny' things. Normally it would be expected trying to read these properties would clear them but the call sequence doesn't quite do that. Looking at the docx/xlsx import it seems that adding the shape to the drawpage ensures the sdr object exists and thus any property set attempts "do the right thing" Miklos can you have a look and make sure the patch is good for the import sequences you handle? marking as fixed
Hi, pulled -> compiled -> tested => correct picture is shown => seems to be fixed indeed. Best regards. JBF