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
Since this is a regression, I'm upping the severity to high.
Confirmed in 4.3 under RHEL 6. Scary stuff- I wonder potentially how many existing documents would be affected by something like this...
also wrong in 4.4.0
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
I'll take a look.
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 );
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.
We are going to backport to 4.4. Thanks for your patience in this matter.
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.
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.
(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.
As this is a one-liner, it would be good to also backport to 4.3.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
This commit seems to have caused Bug 92502.
[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
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.