Summary: | FILEOPEN: Impress shows a picture different from the image stored in the file | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Jean-Baptiste Faure <jbfaure> |
Component: | Impress | Assignee: | Noel Power <nopower> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arnaud.versini, LibreOffice, vmiklos |
Priority: | medium | Keywords: | regression |
Version: | Master old -3.6 | ||
Hardware: | Other | ||
OS: | All | ||
See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=42656 | ||
Whiteboard: | BSA | ||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 37361 | ||
Attachments: |
ODP file with a CC logo in the slide master
Same problem with this file |
Description
Jean-Baptiste Faure
2011-11-06 03:11:07 UTC
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 |