Created attachment 124742 [details] Demo which prints wrongly If all columns are set to "Optimal Column Width", then when the spreadsheet is printed, some columns of numbers appear as "###" instead of the numbers which are visible in the normal spreadsheet view. Whether or not this happens seems to exquisitely depend on the font used and the exact magnification of the table when printing, etc. Attached is an example document. STEPS TO REPRODUCE: 1. Open attached "hashchars_when_printed.ods" 2. Click in corner to select all cells 3. Place cursor in column-header-row and RightClick->Optimal Column Width... Set "Add" to 0. Click OK. 4. Print the page, or File->PagePreview RESULTS: Nothing but "###" EXPECTED RESULTS: WYSIWYG (i.e. the numbers shown in the spreadsheet should appear)
Created attachment 124743 [details] Screenshot (in case it depends on my fonts or something)
Reproducible. Win10x64 Version: 5.1.3.1 (x64) Build ID: 115e0e13d3c8ac1452186ad2394abce2dd5c2b57 CPU Threads: 1; OS Version: Windows 6.19; UI Render: default; 1) Happens with Menu/Tools/Options/LibreOffice calc/General - Use printer metrics for text formatting, enable. 2) Doesn't happen with double click in the line between columns header.
Maybe this should be component "Printing and PDF export?" Any idea if this was OK in other versions?
> Any idea if this was OK in other versions? 4.2 is the earliest build I checked. The bug *is* present in the latest builds (5.2 alpha))
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
Yes, bug is still there in master from 4/9/17 Version: 5.4.0.0.alpha0+ Build ID: 0bc1e8104719b1ed9f8271f9dde407f10fb88df0 I will attach screen-shots showing the spreadsheet before printing, and printed results (please follow the "Steps to Reproduce" to make it happen yourself). -> The key problem is that setting "Optimal Width" columns with zero extra space causes wrong printing with certain data. Using zero extra space is necessary with many data sets containing numerous columns, so this can be a royal pain (you have to check printing with each data set and manually tweek a few columns to avoid the bug; but doing so can make data fall off the right edge of the paper, so you have to re-jigger other columns as well to shrink them.
(I won't attach new screen-shots; the original is sufficient). BTW, the smallest possible "Add:" amount in Optimal Column Width is 0.1" (anything smaller is either rounded up to 0.1" or down to zero). 0.1" is too large when there are many columns, because the extra space adds up and the data no longer fits on the page (or screen). So it would be helpful if this bug is fixed so that zero "Add" can be used reliably.
** Please read this message in its entirety before responding ** 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 there in master Version: 6.1.0.0.alpha1+ Build ID: 8fae8a6cd73b7262c3739bd4acc5c72b54934ff1 CPU threads: 12; OS: Linux 4.15; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-05-22_22:32:05 Locale: en-US (en_US.UTF-8); Calc: group
Dear Jim Avera, 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
Dear Jim Avera, 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 https://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
I don't have the "Sans" font used. In OOo 3.3, LO 6.0 and 7.6, font makes a difference: - with fallback, shows numbers on canvas but ### on print preview. (as OP) - with Liberation Sans, numbers shown in both cases. (OK) Version: 7.6.5.2 (X86_64) / LibreOffice Community Build ID: 38d5f62f85355c192ef5f1dd47c5c0c0c6d6598b CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded In 24.2 and 24.8, results are the same regardless of if I use Liberation Sans or the fallback font: ### on canvas, but numbers shown in print preview. So the opposite of what OP describes! Version: 24.2.1.1 (X86_64) / LibreOffice Community Build ID: 359ef544e625d2ffbfced462ab37bd593ca85fa7 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5234ef71c7459506236d4d0dfe7beb5f00d8cc41 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Maybe that recent change is related to bug 159945. Note that the "use printer metrics" options were removed from the options dialog in LO 7.6 (see https://wiki.documentfoundation.org/ReleaseNotes/7.5#Feature_Removal_/_Deprecation and bug 131136).
(note that issue on canvas might depend on zoom level, so please always test at 100%)
(In reply to Stéphane Guillou (stragu) from comment #12) > In 24.2 and 24.8, results are the same regardless of if I use Liberation > Sans or the fallback font: ### on canvas, but numbers shown in print > preview. So the opposite of what OP describes! In libreoffice-64-24.2 bibisect repo, this started at build [4ce9836c2406d6fc50482782ef4675b5e5078edb] which is: commit 4b743de97fc133623e46827869c4ea3eb845ad47 author Khaled Hosny Mon Jul 17 12:38:41 2023 +0300 committer خالد حسني Sun Jul 23 06:01:56 2023 +0200 tdf#156234: Don’t round glyph coordinates when doing subpixel positioning Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154292 I think this is a better situation than the other way round (i.e. having the bad surprise of printing ### instead of numbers), and this report could be closed as fixed, but any thoughts on the issue on canvas, Khaled?