Bug 108638 - FORMATTING Text size is not scaled correctly according to the zoom factor
Summary: FORMATTING Text size is not scaled correctly according to the zoom factor
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, needsDevAdvice, regression
: 56028 73658 104570 106393 108274 113588 (view as bug list)
Depends on:
Blocks: Font-Rendering Zoom-Issues
  Show dependency treegraph
 
Reported: 2017-06-19 21:41 UTC by Stefan_Lange_KA@T-Online.de
Modified: 2018-11-08 11:39 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
spreadsheet to demonstrate the behavior (8.99 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-06-19 21:41 UTC, Stefan_Lange_KA@T-Online.de
Details
zip file with Screenshots and a new test file (2.12 MB, application/x-zip-compressed)
2017-09-08 20:14 UTC, Stefan_Lange_KA@T-Online.de
Details
sample (13.28 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-09-22 02:14 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan_Lange_KA@T-Online.de 2017-06-19 21:41:20 UTC
Created attachment 134140 [details]
spreadsheet to demonstrate the behavior

When the zoom factor to display a spreadsheet is changed, the text size (width and height) of cell contents is not correctly scaled according the zoom factor.
This results in change of places where text is wrapped and/or the text doesn't fit to cell size.

Steps to reproduce:
- open the attached spreadsheet document "Test_Text_Width_V2.ods"
- when document is opened, zoom factor is 100%, the contents in cell A1 fits to the cell, text "This is a test example to demonstate the behavior." is wrapped into 3 parts:

This is a test example
to demonstate the be-
havior. 

- change zoom factor by menu or by - / + in the right upper corner

Expected behavior: 
Text fits to the cell and places where text is wrapped remain unchanged also when zoom factor is enlarged or decreased - how it is in Writer!

Actual behavior:
When zoom factor is enlarged or decreased, the text is wrapped on other places and/or text doesn't fit to the correctly scaled (?) cell size (--> red arrow appears).
Comment 1 m.a.riosv 2017-06-19 23:02:11 UTC
I'm not sure it's a bug, font proportions have not to be the aame of the screen resolurion
Comment 2 Buovjaga 2017-06-27 17:23:29 UTC

*** This bug has been marked as a duplicate of bug 106111 ***
Comment 3 OfficeUser 2017-09-07 20:25:57 UTC
Bug still present in:
Version: 5.4.0.3
Build-ID: 1:5.4.0~rc3-0ubuntu0.14.04.1~lo2
Comment 4 OfficeUser 2017-09-07 20:27:22 UTC
*** Bug 106393 has been marked as a duplicate of this bug. ***
Comment 5 OfficeUser 2017-09-07 20:28:18 UTC
*** Bug 104570 has been marked as a duplicate of this bug. ***
Comment 6 OfficeUser 2017-09-07 20:37:45 UTC
According to my own experience and duplicate bug 104570 I think this one is NOT a 5.3 regression. I think it is an older bug. Duplicate bug 104570 is reported on 5.3.0 build.

@Stefan L.
Can you confirm this?
Comment 7 OfficeUser 2017-09-07 20:40:02 UTC
Correction:
is reported on 3.5.0
Comment 8 Stefan_Lange_KA@T-Online.de 2017-09-07 21:35:45 UTC
Hi Norbert,

I think I can confirm this. I haven't found an installation file for LO 3.5.0, only for Version 3.6.7.2 (Build ID: e183d5b). But I think that makes no difference.

With this build I have opened my spreadsheet "Test_Text_Width_V2.ods" and I have found the behavior described in this Bug (108638).
I have also reproduced the behavior described in Bug 104570.
Comment 9 V Stuart Foote 2017-09-08 04:37:55 UTC
(In reply to Stefan_Lange_KA@T-Online.de from comment #8)
> I think I can confirm this. I haven't found an installation file for LO
> 3.5.0, only for Version 3.6.7.2 (Build ID: e183d5b). But I think that makes
> no difference.
> 

http://downloadarchive.documentfoundation.org/libreoffice/old/

Of course, please check with current master where calculating the internal leading for fonts has been corrected on builds after > 20170906 [1]

With Version: 6.0.0.0.alpha0+
Build ID: f2c29539d52095ea7b914b20ef7f564469d2aa96
CPU threads: 8; OS: Windows 6.19; UI render: GL; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-09-07_01:40:27
Locale: en-US (en_US); Calc: CL

As I zoom in and out of test document--attached comment 0--the cell holds its format fairly well, including being cut off/non-optimal height. And when the row height is set optimized.

=-ref-=
[1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=0c8b749e602b6743857a9bc4efb24b6183690311
Comment 10 Stefan_Lange_KA@T-Online.de 2017-09-08 20:14:55 UTC
Created attachment 136127 [details]
zip file with Screenshots and a new test file

I have tested with the first attached test file "Test_Text_Width_V2.ods" (from comment 0), means zoomed in and out.
Result:
- I have never seen, that the text doesn't fit to the scaled cell size (no red arrow appeared).
- At the most zoom factors text was wrapped as with zoom factor 100, but the spaces between text end and right borders were different.
- At some zoom factors (e.g. 75, 60, 50, 40) the text was wrapped on other places.

In a second test I have modified the test sheet: When it was zoomed by 400% I have decreased the cell width so that the place where text is wrapped kept unchanged, and saved the sheet as "Test_Text_Width_V2a (cell width smaller).ods" - in the attached zip file. When this sheet is zoomed in or out, also with zoom factors from 159 and 169 the text is wrapped on other places - see screenshots in the zip file!

I have also tested with modified version of "Test_Text_Width_V2.ods", where text was corrected ("demonstrate" instead "demonstate"), results were similar.

The behavior is very much better as in actual version 5.4.1, but still not perfect.
Comment 11 Yousuf Philips (jay) (retired) 2017-09-22 02:05:50 UTC
This bug was introduce in LO 3.5.

Only with 3.4 does the text in attachment 134140 [details] not appear without the red arrow, and zooming in and out in 3.5+ wont ever cause the red arrow to disappear.
Comment 12 Yousuf Philips (jay) (retired) 2017-09-22 02:14:51 UTC
Created attachment 136445 [details]
sample

i noticed this bug with this attached document and it has this behaviour.

100%: fits
110%: doesnt fit (aka red arrow)
120%: fits
140%: doesnt fit
160%: doesnt fit
180%: doesnt fit
200%: doesnt fit
220%: doesnt fit
250%: doesnt fit
280%: doesnt fit
310%: doesnt fit
350%: doesnt fit
390%: fits
Comment 13 Yousuf Philips (jay) (retired) 2017-09-25 10:37:04 UTC
*** Bug 56028 has been marked as a duplicate of this bug. ***
Comment 14 m.a.riosv 2017-09-25 11:53:06 UTC
Looks a bit strange the past being the duplicate. A couple of words explaining why, would be fine.

With the sample on Comment#12, after 'Optimal height' works fine with Menu/Tools/Options/LibreOffice Calc/General - Use printer metrics for text formatting marked, but shows the behavior in the comment without it. 

Version: 5.4.2.1 (x64)
Build ID: dfa67a98bede79c671438308dc9036d50465d2cb
CPU threads: 4; OS: Windows 6.19; UI render: default; 
Locale: es-ES (es_ES); Calc: group
Comment 15 V Stuart Foote 2017-09-25 13:41:50 UTC
(In reply to m.a.riosv from comment #14)
> With the sample on Comment#12, after 'Optimal height' works fine with
> Menu/Tools/Options/LibreOffice Calc/General - Use printer metrics for text
> formatting marked, but shows the behavior in the comment without it. 
>

Confirming that setting "Use printer metrics for text formatting" enabled seems to hold layout correct while scaling--disabled and the layout shifts with zoom levels.

So what is the difference between cell scaling with and without it set that holds its on display layout?

And does the printer in use make a difference. I default to a ghostscript based PDF printer.
Comment 16 m.a.riosv 2017-09-25 14:17:43 UTC
I think there was some issues with this option if they were solved (like tdf#106393), I think the best would be eliminate this option.
Comment 17 V Stuart Foote 2017-09-25 14:31:55 UTC
(In reply to V Stuart Foote from comment #15)
> So what is the difference between cell scaling with and without it set that
> holds its on display layout?
> 

Setting "User printer metrics for text formatting" toggles SCINPUTOPT_TEXTWYSIWYG and SC_UNONAME_PRMETRICS, guess that means the default mode (without precise scaling fidelity) is necessary for performance of the sheet?

But have to wonder if any improvement could be made to layout fidelity of the general case without impacting performance?

=-ref-= 

https://opengrok.libreoffice.org/xref/core/sc/source/core/tool/inputopt.cxx#112
Comment 18 Yousuf Philips (jay) (retired) 2017-09-25 15:04:25 UTC
(In reply to m.a.riosv from comment #14)
> Looks a bit strange the past being the duplicate. A couple of words
> explaining why, would be fine.

Because this has more QA work in it.

> With the sample on Comment#12, after 'Optimal height' works fine with
> Menu/Tools/Options/LibreOffice Calc/General - Use printer metrics for text
> formatting marked, but shows the behavior in the comment without it. 

Yes enabling 'use printer metrics' solves the issue, but it after enabling it, the height of the row goes from 1.08" to 1.15" and 3.4 didnt have 'use printer metrics' enabled. didnt get why you had to do 'optimal height'.

(In reply to V Stuart Foote from comment #17)
> Setting "User printer metrics for text formatting" toggles
> SCINPUTOPT_TEXTWYSIWYG and SC_UNONAME_PRMETRICS, guess that means the
> default mode (without precise scaling fidelity) is necessary for performance
> of the sheet?

Was this introduced in 3.5 that caused the regression?
Comment 19 Stefan_Lange_KA@T-Online.de 2017-09-25 15:35:19 UTC
(In reply to m.a.riosv from comment #16)
> I think there was some issues with this option if they were solved (like
> tdf#106393), I think the best would be eliminate this option.

... or set this option to "On" as default - when it is easier!
In the Help to this option could be added a hint, what happens when the option is set to "off" (e.g. the behavior described in this and similar bugs).
Comment 20 V Stuart Foote 2017-09-25 16:09:01 UTC
@Koehi, Eike -- the needDevAdice to you both. 

How bad would the performance impact on Calc be for toggling the WYSIWYG of the Use printer metrics enabled by default? 

Failing that, is there another way to hold the cell multiline text in better proportion to the cell size while scaling for zoom in or out that would not be a performance drag?
Comment 21 V Stuart Foote 2017-09-25 17:56:57 UTC
(In reply to V Stuart Foote from comment #20)
> @Koehi, Eike -- the needDevAdice to you both. 
> 
> How bad would the performance impact on Calc be for toggling the WYSIWYG of
> the Use printer metrics enabled by default? 
> 
> Failing that, is there another way to hold the cell multiline text in better
> proportion to the cell size while scaling for zoom in or out that would not
> be a performance drag?

So reading through the code looks like the magic happens in docsh3.cxx in CalcOutputFactor, comparing a "printer" output width of a test string to a "window" output width of the same test string and calculating a ratio for  

When use printer metrics is not enabled, the PrtToScreenFactor gets a fixed 1.0 -- so assume elsewhere it skips height recalculations that are forced when printer metrics are enabled. 

But, wonder if there _also_ are some the same rounding issues for cell width when UI is scaled for zooms, like were just fixed for DirectWrite font height on Windows.

=-ref-=
https://opengrok.libreoffice.org/xref/core/sc/source/ui/docshell/docsh3.cxx?a=true&h=361#353

https://opengrok.libreoffice.org/xref/core/sc/source/ui/docshell/docsh.cxx?a=true&h=621#2649
Comment 22 OfficeUser 2017-09-26 19:44:43 UTC
(In reply to V Stuart Foote from comment #21)

Thanks for investigating these issue and that you found out what this option exactly does.

With this knowledge, I think that turning on "Use printer metrics" by default is NOT a way to go. I expect that PrtToScreenFactor varies with environments thus leading to different on-screen results. Can you confirm this?


I am wondering why LibreOffice has this (OOo-inherited) implementation this way. If printer output varies different on every environment I think it would make more sense to use such a factor to adjust the printer output instead of the on-screen output. Just my two cents...
Comment 23 Xisco Faulí 2017-10-27 10:56:58 UTC
*** Bug 73658 has been marked as a duplicate of this bug. ***
Comment 24 Xisco Faulí 2017-10-27 10:57:03 UTC
*** Bug 108274 has been marked as a duplicate of this bug. ***
Comment 25 V Stuart Foote 2017-11-02 19:56:48 UTC
*** Bug 113588 has been marked as a duplicate of this bug. ***
Comment 26 Buovjaga 2018-06-27 17:54:36 UTC
(In reply to Yousuf Philips (jay) (retired) from comment #12)
> Created attachment 136445 [details]
> sample
> 
> i noticed this bug with this attached document and it has this behaviour.
> 
> 100%: fits
> 110%: doesnt fit (aka red arrow)
> 120%: fits
> 140%: doesnt fit
> 160%: doesnt fit
> 180%: doesnt fit
> 200%: doesnt fit
> 220%: doesnt fit
> 250%: doesnt fit
> 280%: doesnt fit
> 310%: doesnt fit
> 350%: doesnt fit
> 390%: fits

Bibisected with Linux 43all and the change seems to be in this range: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=ceb55cd688cebede8cef8408540019fe54528869...55c5ea43a59e505297fb6fa20b77aaa28f7c67bc

It certainly has many Calc commits picked by Eike (done by others), but nothing jumps out to me. Eike is already in CC here.