Bug 61549 - FILEOPEN impossible for particular .odg (valid ODF) saved from same version
Summary: FILEOPEN impossible for particular .odg (valid ODF) saved from same version
Status: RESOLVED DUPLICATE of bug 60075
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Whiteboard: BSA bibisected40
Keywords: regression
Depends on:
Reported: 2013-02-27 10:06 UTC by Andreas Balg
Modified: 2013-07-19 11:41 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

one of the files that cannot be opened anymore - draw crashes immediately trying to open it. (468.57 KB, application/vnd.oasis.opendocument.graphics)
2013-02-27 10:06 UTC, Andreas Balg
.svg files used to create the document (244.51 KB, application/zip)
2013-02-27 11:54 UTC, Andreas Balg
bibisect40 log (2.81 KB, text/plain)
2013-02-27 14:03 UTC, Jorendc
diff between flat odf exports (133.55 KB, text/plain)
2013-03-13 13:56 UTC, Michael Meeks

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Balg 2013-02-27 10:06:58 UTC
Created attachment 75625 [details]
one of the files that cannot be opened anymore - draw crashes immediately trying to open it.

Problem description: 
A drawing that was created and saved in this version of LO Draw cannoit be opened again after saving it.

Steps to reproduce:
1. Create New drawing
2. Fill it with elements (sorry don't know what exactly makes the problem) 
3. Save it, Close Draw
4. Try to load the saved document

Current behavior:
There is no error - draw loads, you get a ver fast glimpse of a window trying to open that disappears immediately without an error 

Expected behavior:
Open the drawing and be able to see and work with it
Operating System: Windows 7
Version: release
Comment 1 Rainer Bielefeld Retired 2013-02-27 11:00:40 UTC
More or less [Reproducible] with Server Installation of "LibO   -  German UI / German Locale  [Build ID: 2c0c17a6e4bee0ee28131ea4bdc47edc700d659)]"  {tinderbox: @6, pull time  2013-02-1920:00(?)} on German WIN7 Home Premium (64bit) with newly created user profile ….\LODev\4\: File will not be opened, nothing happens when I try to open reporter's sample from LibO start Center File Dialog

Same FILEOPEN effect with
FILEOPEN  Works fine with 3.6.5

That's a little strange. Reporter's sample is valid ODF 1.2 due to <http://odf-validator2.rhcloud.com/odf-validator2/>, so LibO should be able to open it.

I saved the document from 3.6.5 as strict 1.2, compatible and extended, all 3 opened fine with and, and documents saved from in the same mode opened fine in again.

I found out that in my documents saved from 3.6.5 3 three .svg pictures are missing in "pictures" sub folder (because of that all my documents have 423 kB instead of 469 kB), no idea whether that is related to the problem.

May be we should open a second Bug concerning the FILESAVE problem?

@Andreas Balg:
Do these results bring up any ideas concerning the reasons?
Can you attach the latest version of the document what can be opened with LibO and an instruction how to created the damaged one?
Comment 2 Andreas Balg 2013-02-27 11:54:52 UTC
Created attachment 75628 [details]
.svg files used to create the document

Unfortunately I cannot provide a former working revision of the document - I created it and tried to open it again after saving and it crashed.

No idea which change finally caused it to fail but it's true that I added some .svg graphics from openclipart.org as well as one or two I created/edited in Inkscape (latest 0.48.4) - I could give those missing .svg files to you.

I attached the svg files used in this document for you. Hope that 'll help in any way.
Comment 3 Rainer Bielefeld Retired 2013-02-27 12:28:15 UTC
I did some tests with a document based on reporter's sample, saved from LibO 3.6.5, with added .svg from att. 2013-02-27 11:54 UTC, Andreas Balg. I can not reproduce the FILESAVE problem. 

But the fileopen problem should be checked as long as we do not know what happens. Reporter's sample can't be opened with AOOo 3.4.1, either.
LibO 3.4.5 and LibO 3.3.3 open the document without problems (others not tested).

Currently only normal priority.

@Andreas Balg:
Please open a separate Bug for the FILESAVE problem if you can make it reproducible (and/or more documents are affected) and leave a comment here.

Please add Witeboard tag “bibisectrequest” if you think that a bibisect result can ease your work.
Please change  Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf.
Comment 4 Jorendc 2013-02-27 14:03:24 UTC
I can confirm this behavior using Linux Mint 14 x64.

See bibisect output
Comment 5 Jorendc 2013-02-27 14:03:47 UTC
Created attachment 75638 [details]
bibisect40 log
Comment 6 Michael Meeks 2013-03-13 13:56:58 UTC
Created attachment 76474 [details]
diff between flat odf exports

So - a great technique with this kind of bug is to save as flat-odf, then you can diff -u -w between versions to see what exactly changed.

I attach such a sample diff; things like:

   <style:style style:name="P1" style:family="paragraph">
-   <style:text-properties fo:font-size="9pt" style:font-size-asian="18pt" style:font-size-complex="18pt"/>
-  </style:style>
-  <style:style style:name="T1" style:family="text">
-   <style:text-properties fo:font-size="9pt" style:font-size-asian="18pt" style:font-size-complex="18pt"/>
+   <style:chart-properties/>
+  <style:style style:name="T1" style:family="text"/>
   <text:list-style style:name="L1">
    <text:list-level-style-bullet text:level="1" text:bullet-char="●">

Look rather suspicious - this is from before -> after.

Why are T1 and P1 much empty styles, missing fo:font-size="9" in this new export ? - most odd.
Comment 7 Michael Meeks 2013-03-13 14:01:38 UTC
terribly sorry - comment in wrong bug ;-) ignore me above.
Comment 8 Michael Meeks 2013-03-13 21:26:21 UTC
Interestingly, it is the presence of the OLE objects that causes the grief; that (it seems) clobbers the PropertyMap used for serializing the text objects: which is most odd.

Still digging ...
Comment 9 Michael Meeks 2013-03-13 21:27:10 UTC
and again a comment in the wrong bug - sorry pardon.
Comment 10 Michael Meeks 2013-06-12 12:39:40 UTC
No crash on open for me in master / 4.1 and the document looks nicely rendered - it does crash for my 4.0.4 rc1 install - so apparently we need to back-port some fix here.
Comment 11 David Tardon 2013-07-19 11:41:26 UTC
review for 4.0: https://gerrit.libreoffice.org/4982

*** This bug has been marked as a duplicate of bug 60075 ***