Description: I have a Win 10 PC with LO 5.2.6.2 installed, and a Win Vista PC with LO 5.3.3.2 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 v5.3.2.2 and fresh installed v5.3.3.2 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. Actual Results: Open the document in each machine described above. Expected Results: 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. Reproducible: Always User Profile Reset: No Additional Info: 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 Version: 5.2.5.0.0+ 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 Version: 5.5.0.0.alpha0+ 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? Thanks 17d8234546ccc7b6cd69f3288c5ee086d48b7b1c is the first bad commit commit 17d8234546ccc7b6cd69f3288c5ee086d48b7b1c Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Nov 3 22:33:58 2016 +0100 source 5d9d0f3c979732ade57b9c4c4960dd030ffdc9f9 author Justin Luth <justin_luth@sil.org> 2016-11-02 12:15:55 (GMT) committer Justin Luth <justin_luth@sil.org> 2016-11-03 19:02:41 (GMT) commit 5d9d0f3c979732ade57b9c4c4960dd030ffdc9f9 (patch) tree 5fec72a40be7dbf15f208498494213cd6f59c114 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.
*** Bug 146717 has been marked as a duplicate of this bug. ***