Bug 83983 - FILEOPEN: Regression in 4.4 master loading an ODT which contains a style with style:font-independent-line-spacing="true"
Summary: FILEOPEN: Regression in 4.4 master loading an ODT which contains a style with...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
(earliest affected) Master
Hardware: Other All
: high major
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Reported: 2014-09-17 11:58 UTC by Matthew Francis
Modified: 2017-02-24 18:49 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Minimised example (see comment #0 for link to original document) (16.01 KB, application/vnd.oasis.opendocument.text)
2014-09-17 11:59 UTC, Matthew Francis

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Francis 2014-09-17 11:58:33 UTC
The following file loads and displays correctly in LO, but fails to load at all in 4.4 master (observed on both OSX and Linux):

(from bug 83755)

On 4.4 master, instead of loading, it throws up a dialog containing:

"Read-Error. Error reading file."

and outputs the following console log message (in a debug build):

warn:legacy.osl:25295:1:sw/source/filter/xml/swxml.cxx:268: uno exception caught while importing:
Unknown property: FontIndependentLineSpacing

The offending XML within the ODT appears to be this:

<style:paragraph-properties ..... style:font-independent-line-spacing="true"/>

(see the attached minimised example, which likewise loads in but not 4.4 master)

Bisecting backwards, the dialog starts to appear as of:

commit b0f54746be824343379ea957d4220102e14c0f75
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Fri Jul 18 13:38:25 2014 +0100

    coverity#1224992 Uncaught exception

However, this is not the cause of the bug, but merely converts a fatal exception into a non-fatal error. Further back, the actual failure to load is introduced by:

commit 7d9bb549d498d6beed2c4050c402d09643febdfa
Author: Armin Le Grand <alg@apache.org>
Date:   Mon Jun 2 15:00:50 2014 +0000

    Related: #i124638# Second step of DrawingLayer FillAttributes...

Even before this commit, there is a further issue that the rendering of the original document is no longer correct. I haven't narrowed down exactly where that broke.
Comment 1 Matthew Francis 2014-09-17 11:59:52 UTC
Created attachment 106424 [details]
Minimised example (see comment #0 for link to original document)
Comment 2 Julien Nabet 2014-09-17 20:23:22 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.
Comment 3 Julien Nabet 2014-09-17 21:17:01 UTC
Trying to gdb it, I saw that there's a parsing problem indicated by:
bExceptionWasThrown = true
But then I'm a bit lost.
Comment 4 Miklos Vajna 2014-09-24 15:52:44 UTC
If this is a regression, please add "regression" to keywords.
Comment 5 Xisco Faulí 2014-10-23 14:55:31 UTC
It seems that the commit that caused this regression was identified. (Or at
least a commit is suspected as the offending one.)

Thus setting keyword "bisected".
Comment 6 Robinson Tryon (qubit) 2015-12-13 11:11:04 UTC Comment hidden (obsolete)
Comment 7 Xisco Faulí 2016-09-26 15:03:13 UTC
Adding Cc: to Armin Le Grand
Comment 8 Justin L 2017-02-24 18:49:51 UTC
Some clarity is needed on this bug report.  The inability to open was resolved already in 4.4development.

This is a very odd document.  The text is in color WHITE, and it is only a blue frame (without any associated textbox) in the background that makes the white characters visible. The page size is huge 90cm x 140cm

In 4.3, it looks like the AREA color spills far outside of the frame.  That was fixed in 4.4 by Miklos Vajna CommitDate: Tue Jun 17 01:16:20 2014 +0200
        svx: fix VML export of rectangles imported from drawingML

Closing this bug. The specific problem of not being able to open has been resolved. The vague "mis-rendering" problem is only because something broken was tweaked to look like nice.