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).
I'm not sure it's a bug, font proportions have not to be the aame of the screen resolurion
*** This bug has been marked as a duplicate of bug 106111 ***
Bug still present in: Version: 5.4.0.3 Build-ID: 1:5.4.0~rc3-0ubuntu0.14.04.1~lo2
*** Bug 106393 has been marked as a duplicate of this bug. ***
*** Bug 104570 has been marked as a duplicate of this bug. ***
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?
Correction: is reported on 3.5.0
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.
(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
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.
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.
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
*** Bug 56028 has been marked as a duplicate of this bug. ***
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
(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.
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.
(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
(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?
(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).
@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?
(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
(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...
*** Bug 73658 has been marked as a duplicate of this bug. ***
*** Bug 108274 has been marked as a duplicate of this bug. ***
*** Bug 113588 has been marked as a duplicate of this bug. ***
(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.
Dear Stefan_Lange_KA@T-Online.de, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The bug is still present in Version: 6.3.3.2 (x64) Build-ID: a64200df03143b798afd1ec74a12ab50359878ed CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: CL and also in Version: 6.4.0.0.alpha1+ (x64) Build-ID: 25c390e17a7f1c018b5eed1ef7dfd568b76f4a84 CPU-Threads: 4; BS: Windows 10.0 Build 18362; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: CL I have also repeated tests with older versions. The oldest version I can reproduce the bug with is LibreOffice 3.5.0rc3 Build-ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735 The problem (text is wrapped at different positions depending on zoom factor) does not occur in LO 3.3 and LO 3.4, but the postion where cell contents is wrapped in LO 3.3 is different to the position where text is wrapped in LO 3.4.
Created attachment 155657 [details] zip file with screenshots as addition to comment 28
Changing priority to 'highest' since this a regression and the number of duplicates is higher than 5 or the number of people in CC higher than 20
*** Bug 132135 has been marked as a duplicate of this bug. ***
*** Bug 136403 has been marked as a duplicate of this bug. ***
*** Bug 142893 has been marked as a duplicate of this bug. ***
*** Bug 144370 has been marked as a duplicate of this bug. ***
I don't know if this is related, but in terminal version of LO I get these messages: This looks connected: warn:legacy.osl:111664:111664:sc/source/core/tool/viewopti.cxx:357: property value missing Full messages here: warn:unotools.config:111664:111664:unotools/source/config/configitem.cxx:423: ignoring XHierarchicalNameAccess FormulaMark com.sun.star.container.NoSuchElementException message: "FormulaMark at /home/tdf/lode/jenkins/workspace/lo_gerrit/tb/src_master/configmgr/source/access.cxx:439" warn:legacy.osl:111664:111664:sc/source/core/tool/viewopti.cxx:357: property value missing warn:sfx.control:111664:111664:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 25917 warn:sfx.control:111664:111664:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 26189 warn:sfx.control:111664:111664:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 26190 warn:sfx.control:111664:111664:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 25917 warn:sfx.control:111664:111664:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 26189 warn:sfx.control:111664:111664:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 26190
(In reply to Rafael Lima from comment #35) > ... > https://primaseo.xyz/ > ... > So I'd like to know if this was one of the bugs fixed for this tender. Well if any progress on inline math element of the tender, it has not made it into current master against 7.5.0
FWIW, the current master build seems to work perfectly except at extremely small magnifications, where the line heights seem too tall and so the bottom line is clipped off. The problem appears around 20% magnification. But this is pretty tiny! I'll attach a screenshot (master_20percent_3rdlinelost.png) Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d0dcd87788910e3c9f67a2b68534019c05b77bad CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 192155 [details] master_20percent_3rdlinelost.png (lines too tall at 20% magnification)