I have a Win 10 PC with LO 22.214.171.124 installed, and a Win Vista PC with LO 126.96.36.199 installed. I have several documents, each of which is a 1-page document when opened on the Win 10 machine. However each document is expanded (i.e. scaled up) when opened on the Win Vista machine; everything (text size, line spacing, width, height) appears to be scaled up by about 5 percent. The result is that each document is 2 pages when viewed or printed on the Vista machine. Each document contains a table that is about 6-3/8 in. X 9-1/8 in. when printed from the Win 10 machine; using the Vista machine the table is about 6-3/4 in. X 9-3/4 in. I uninstalled v188.8.131.52 and fresh installed v184.108.40.206 on the Vista machine, but the scaled up document did not change. I would like to see the Vista documents scale down to the same size as those produced on the Win 10 machine.
Open the document in each machine described above.
Win 10 machine: document opens/prints "normal" size on 1 sheet/page.
Win Vista machine: document open/print "scaled-up" size on 2 sheets/pages.
User Profile Reset: No
I will attempt a User Profile reset. I can forward the document(s) that demonstrate the issue (I'll try to add attachment if/when I see a prompt).
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 133398 [details]
A 1-page Table
I can confirm. Single page document with
Build ID: a4d4fbeb623013f6377b30711ceedb38ea4b49f8
CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL;
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-2, Time: 2016-12-24_14:43:55
Locale: nl-NL (nl_NL); Calc: CL
Multipage document with
Build ID: d57e6cd9dcc96112994ca2b14ac45896e86b26e5
CPU threads: 4; OS: Windows 6.19; UI render: default;
TinderBox: Win-x86@42, Branch:master, Time: 2017-05-18_22:43:07
Locale: nl-NL (nl_NL); Calc: CL
Probably related to the new font rendering. Not quite sure if bibisecting is helpful
This seems to have begun at the below commit.
Adding Cc: to Justin Luth ; Could you possibly take a look at this one?
17d8234546ccc7b6cd69f3288c5ee086d48b7b1c is the first bad commit
Author: Jenkins Build User <firstname.lastname@example.org>
Date: Thu Nov 3 22:33:58 2016 +0100
author Justin Luth <email@example.com> 2016-11-02 12:15:55 (GMT)
committer Justin Luth <firstname.lastname@example.org> 2016-11-03 19:02:41 (GMT)
commit 5d9d0f3c979732ade57b9c4c4960dd030ffdc9f9 (patch)
parent 2a818a0aafac218ca09bb079d7f2cf0879385e4a (diff)
there is a function for that: CalcLineSpace(xx, bEvenIfNoLine)
I'm not sure what I should do with this regression (which is connected to bug 41542). The problem is that the document's paragraph properties define a synchronized padding value for all four borders - instead of only defining the spacing for the border that is showing. Before 5.3, LO improperly (according to ODF specs) ignored that padding setting.
So, it is not really a current bug. Unfortunately, in various ways LibreOffice previously allowed you to create improperly designed documents that specified a spacing that it didn't display. (Usually LO automatically sets the value to zero when a border is removed.)
The way to fix up the document in <=LO53 is to enable the 4 borders, reset the spacing to 0, unsynchronize, clear the borders except for the desired ones, and then set the desired spacing for those borders. (It is easier in LO54 because the UI ALWAYS allows editing of the padding - they are never grayed out.)
I'm going to mark as notabug. I can't imagine any way for the computer to know when the document was designed to work one way or the other. These documents will just need to be fixed manually.
*** Bug 117449 has been marked as a duplicate of this bug. ***
*** Bug 121428 has been marked as a duplicate of this bug. ***
*** Bug 134954 has been marked as a duplicate of this bug. ***
(In reply to Justin L from comment #7)
> *** Bug 134954 has been marked as a duplicate of this bug. ***
Auto of curiosity. The formula frame has the wrong dimensions, and it's solved by entering. Not sure what the scope/exten of the issue is. So if a fix being useful or not. Related to the formula case: Is there a way to detect if it's a formula frame, emulate the access in the background while processing. [Not sure how expensive that would be]. With maybe a limited 'scope' to that for certain dimensions [which ends up in guessing what problematic formula's would look like]
There is surely one file with 390 pages and 2000 formula's around.. And manually checking for flaws isn't something you want to do.