Download it now!
Bug 107946 - Document Scales Up
Summary: Document Scales Up
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 117449 121428 134954 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-05-19 03:41 UTC by alcpe@afo.net
Modified: 2020-07-20 18:54 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
A 1-page Table (15.54 KB, application/vnd.oasis.opendocument.text)
2017-05-19 03:44 UTC, alcpe@afo.net
Details

Note You need to log in before you can comment on or make changes to this bug.
Description alcpe@afo.net 2017-05-19 03:41:59 UTC
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
Comment 1 alcpe@afo.net 2017-05-19 03:44:16 UTC
Created attachment 133398 [details]
A 1-page Table
Comment 2 Telesto 2017-05-23 08:56:34 UTC
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
Comment 3 raal 2017-05-23 16:08:46 UTC
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 sha: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)
Comment 4 Justin L 2017-05-23 18:24:13 UTC
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.
Comment 5 Justin L 2018-06-12 19:18:00 UTC
*** Bug 117449 has been marked as a duplicate of this bug. ***
Comment 6 Justin L 2018-11-15 13:40:36 UTC
*** Bug 121428 has been marked as a duplicate of this bug. ***
Comment 7 Justin L 2020-07-20 18:31:42 UTC
*** Bug 134954 has been marked as a duplicate of this bug. ***
Comment 8 Telesto 2020-07-20 18:54:58 UTC
(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.