Bug 87510 - FILEOPEN: Line spacing wrong when opening particular legacy odt document
Summary: FILEOPEN: Line spacing wrong when opening particular legacy odt document
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.0.alpha1
Hardware: Other All
: high normal
Assignee: Not Assigned
URL:
Whiteboard: target:4.5.0 target:4.4.0.2
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Paragraph-Line-Spacing
  Show dependency treegraph
 
Reported: 2014-12-19 21:55 UTC by tmacalp
Modified: 2017-07-27 19:42 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Example document with embedded screenshot exhibiting bug (124.95 KB, application/vnd.oasis.opendocument.text)
2014-12-19 21:55 UTC, tmacalp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tmacalp 2014-12-19 21:55:23 UTC
Created attachment 111059 [details]
Example document with embedded screenshot exhibiting bug

We have a legacy ODT that requires precise formatting to use the entire page.  When we attempted to upgrade to LibreOffice 4.3.4, this document no longer fit on the set number of pages.

It appears that each line has increased its spacing by just a little bit.  This extra space between lines adds up over the document.  In our case, the document had 3 columns of small text.  This made the document completely unusable in any version >4.3.X.  Resaving the document with an affected version did not seem to corrupt the document, but printing with an affected version does show the error.

I've attached an example document created from the original.  I've tried to simplify it as much as possible and have included example screenshots within the document.

The document contains a number of lines of text containing the letter E.  I have created lines that are anchored to the page that indicate the exact top and bottom of where the E's show under LibreOffice 4.2 and before.  There are lines to the side that indicate the extent of the cursor when placed in those lines.

Steps to reproduce:
1. Open example document

Expected:
The lines should match exactly where the text starts and finishes.

Actual:
The text expands by a few points for each line present. The resulting final line of E's is far from where it should be.

Note that this does not seem to affect creating/opening new documents.  I haven't been able to create a new document with any version of LO that I have installed that shows this bug.  That said, we have lots of legacy documents and haven't experienced the full impact of this bug.

I've bibisected:

7a61c8796f924f9fa3738366bdac9666b7011fa4 is the first bad commit
commit 7a61c8796f924f9fa3738366bdac9666b7011fa4
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Tue May 13 15:14:16 2014 +0000

    source-hash-46cfcd5a05aa1d13fecd73f5a25b64b8d8dd6781
    
    commit 46cfcd5a05aa1d13fecd73f5a25b64b8d8dd6781
    Author:     Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
    AuthorDate: Sun Apr 20 05:17:30 2014 +0200
    Commit:     Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
    CommitDate: Sun Apr 20 05:17:30 2014 +0200
    
        Version 4.3.0.0.alpha1, tag libreoffice-4.3.0.0.alpha1
    
        Change-Id: I39d2c181787fa552f24afc679c4e10098fdc7ac5

:100644 100644 721936720bbe768fea93bfbed4fe0c1be02421c1 1600996714e99839b077838619e5148181d84b0a M      ccache.log
:100644 100644 1e3a111c5707418e8b8b5b0671446fcd22a08814 fb42ce6bcd1a1cbdb65e181de8f0a4065606dbb6 M      commitmsg
:100644 100644 91b06ecf2b1a1e00a61cdd28f9afbe350a81311a 3f9c5ee08a5e30a658751d54b7916995c9992b89 M      make.log
:040000 040000 a54dc86fd10731cb5522ae7a2bd87023b98499f6 2aed4c61a40c9e784619a68135e100ee931708e3 M      opt


$ git bisect log
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [752769ad0d2179e17ea0a08cc9004df7b890305b] source-hash-60c64b437c6678dd1d3fa3a6fc2b7da0480890d4
git bisect start 'latest' 'last42onmaster'
# good: [4fcd68ce4979f85fda4568f4b419a4b41d07345f] source-hash-2c4621c87ed3a7b19de195c21494c9a381e72b2e
git bisect good 4fcd68ce4979f85fda4568f4b419a4b41d07345f
# skip: [422186458e0b4db00c7e26b54d5b631f83bcad2a] source-hash-6948bf58ce181b17f60ef81f10205ef4dac50cc6
git bisect skip 422186458e0b4db00c7e26b54d5b631f83bcad2a
# good: [a0b33bffff9c787dce71a13b344f06ae1453026b] source-hash-02e0be069e57e724c51f23e2e31b77657a6a1d3d
git bisect good a0b33bffff9c787dce71a13b344f06ae1453026b
# bad: [16d0a5059bce9198bfae647a72dc06b438be583f] source-hash-944c78ecb91608f4c3e9bab32fdbc90c67326525
git bisect bad 16d0a5059bce9198bfae647a72dc06b438be583f
# good: [5e7af1ea4d6ff32d05a2eb182f0b548700601784] source-hash-213571db0e69db5d8d16d16e8a5c428b824e80d1
git bisect good 5e7af1ea4d6ff32d05a2eb182f0b548700601784
# bad: [cb4fd88402c426174f9cc9ff08c3b86ae84820e5] source-hash-e15223582710e9e2e31fad2f557df6ee99501fd0
git bisect bad cb4fd88402c426174f9cc9ff08c3b86ae84820e5
# skip: [127668cf4fda59e09382becddee2939848cefebf] source-hash-8b7aff3d430649eed279a81984cb6f5c8a1a4f66
git bisect skip 127668cf4fda59e09382becddee2939848cefebf
# good: [19604661a278cb5b1b513d5bcf9e12eb85f4715f] source-hash-f05861de995f8d4edb1a97c616d050f55ec04c32
git bisect good 19604661a278cb5b1b513d5bcf9e12eb85f4715f
# bad: [425d8d0804727d55d9a836626615f0c7ca7c6a06] source-hash-31792ca5a2ac093bd922723acc2b07ed225e5eaa
git bisect bad 425d8d0804727d55d9a836626615f0c7ca7c6a06
# bad: [7a61c8796f924f9fa3738366bdac9666b7011fa4] source-hash-46cfcd5a05aa1d13fecd73f5a25b64b8d8dd6781
git bisect bad 7a61c8796f924f9fa3738366bdac9666b7011fa4
# first bad commit: [7a61c8796f924f9fa3738366bdac9666b7011fa4] source-hash-46cfcd5a05aa1d13fecd73f5a25b64b8d8dd6781
Comment 1 tmacalp 2014-12-19 21:57:04 UTC
Since this is a regression, I'm upping the severity to high.
Comment 2 crxssi 2014-12-20 04:53:33 UTC
Confirmed in 4.3 under RHEL 6.  Scary stuff- I wonder potentially how many existing documents would be affected by something like this...
Comment 3 Cor Nouws 2014-12-21 19:17:34 UTC
also wrong in 4.4.0
Comment 4 Matthew Francis 2014-12-23 03:19:28 UTC
A follow-up source bisect points to the below commit.

Adding Cc: to chris.sherlock79@gmail.com. Could you possibly take a look at this? Thanks


commit 588bb542bebdee5a67bd4695253c70646fb8a303
Author: Chris Sherlock <chris.sherlock79@gmail.com>
Date:   Sun Apr 20 11:47:58 2014 +1000

    fdo#74702 Only VirtualDevice should handle the Word ext lead bug
    
    In #i60945# it was discovered that Unix's leading external font spacing
    causes problems with the display of documents. Therefore, the reference
    device implemented a workaround, which was to set the spacing to zero.
    However, the reference device is a VirtualDevice, so it should really be
    handled there, not in OutputDevice. I have added a new protected function
    to OutputDevice, GetFontExtLead() that handles this.
    
    Change-Id: I1b84ee7d9f7ae96841b441b52705e67c8115ae5c
Comment 5 Chris Sherlock 2014-12-23 13:03:48 UTC
I'll take a look.
Comment 6 Chris Sherlock 2014-12-23 13:16:36 UTC
OutputDevice::GetFontMetric() is the issue I think. When I refactored the code, I'm rather afraid I didn't remove the line:

aMetric.mpImplMetric->mnExtLeading = ImplDevicePixelToLogicHeight( pMetric->mnExtLeading );
Comment 7 Commit Notification 2014-12-23 13:37:00 UTC
Chris Sherlock committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6acf1c7ab7b514a8713ed66b74efbee1a75f029a

vcl: fdo#87510 regression in GetFontMetric

It will be available in 4.5.0.

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.
Comment 8 Chris Sherlock 2014-12-23 14:16:07 UTC
We are going to backport to 4.4. Thanks for your patience in this matter.
Comment 9 Commit Notification 2014-12-23 15:22:51 UTC
Chris Sherlock committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a7f76a197900e7ece5d09fed2bf7920a42425e9c&h=libreoffice-4-4

vcl: fdo#87510 regression in GetFontMetric

It will be available in 4.4.0.2.

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.
Comment 10 tmacalp 2014-12-24 15:52:32 UTC
I tested both the example document and our original document with nightly versions of both 440 and master using 64bit Fedora 20.  Everything appears to be back to normal, so I'll mark this as resolved-fixed.

Thanks to everyone involved for speedily tracking and fixing this bug!  I'm quite impressed.
Comment 11 Matthew Francis 2014-12-24 17:30:05 UTC
(In reply to tmacalp from comment #10)

Thanks to you for providing a gold-standard reproduction aid. It made isolating the problematic commit extremely easy.
Comment 12 Yousuf Philips (jay) (retired) 2015-01-07 13:00:42 UTC
As this is a one-liner, it would be good to also backport to 4.3.
Comment 13 Robinson Tryon (qubit) 2015-12-17 08:42:04 UTC Comment hidden (no-value, obsolete)
Comment 14 Timur 2017-01-05 10:13:54 UTC
This commit seems to have caused Bug 92502.
Comment 15 vihsa 2017-07-27 04:04:55 UTC
[1] reproducible

version: 5.3.0.0.alpha1+
build ID: 4136757

device: lyf flame 3 [ ls-4001 ]
os: android 5.1

[2] unable to open

Version: 6.0.0.0.alpha0+
Build ID: 1e87e93

device: lyf flame 3 [ ls-4001 ]
os: android 5.1
Comment 16 Timur 2017-07-27 15:26:34 UTC
I tested this because of krishna's comment and:
- in Linux this is fixed as written and file opens fine with 6.0+
- but in Windows I always have the same result, what's here marked "wrong", can't say why, is it Bug 92502 or what?
- can't say what is krishna's 5.3 "reproducible" 
- as for krishna's 6.0+ "unable to open", that can be a different fileopen bug, please file and mark for Android.