Description: A small change to the width isn't changing the format from "Letter" to "User". (Presumably a rounding error when comparing floats.) Steps to Reproduce: 1. Open LibreOffice and create new Writer doc 2. Add some text 3. Format->Page and open the Page tab 4. (Letter Format is set by default) 5. Click the up arrow to change the width from "21.59 cm" to "21.60 cm" Actual Results: The Format dropdown remains at "Letter". Expected Results: The Format dropdown should change to "User". Reproducible: Always User Profile Reset: No Additional Info: Version: 5.4.0.3 Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 8; OS: Mac OS X 10.12.6; UI render: default; Locale: en-CA (en_CA.UTF-8); Calc: group User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
@Andy : Letter format is only the default for certain locale / language versions of LibreOffice. Does this also occur in other locale environments, where the default page size is A4 for example ?
For example, testing with Version: 6.0.0.0.alpha0+ Build ID: 4dd34cd4b829bdc1679b11f19e957313f11620cd CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group where A4 is the default page size, I can not reproduce the issue. As soon as I modify the default page dimension either horizontally or vertically, the PageSize dropdown gets set to user. To me, this problems seems limited to en-US and en-Ca versions of LibreOffice where the default page size is Letter. This might tie in to the printing problems encountered with the same locale versions and default page size.
Thanks Alex. I'm not sure reading your response if you set it to Letter and tried to reproduce? I think you should be able to reproduce this by using version 5.4.0 and just setting it to Letter in step 4 and do step 5. To me it looks like a rounding issue with the contents of the dropdown. A4 is 21.00 and 29.70, but letter is 21.59 and 27.94. Clicking the up arrow changes 21.59 to 21.60. My guess is that the code that's checking for a change to a non-standard size is rounding during the comparison to items in the list (i.e. it thinks 21.59 and 21.60 are the same, so it stays on Letter).
On Mac OS 10.12.6, using Version: 5.4.0.3 Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; Locale: en-CA (en_US.UTF-8); When I change the width of Letter size by .01 increments - 21.62 or greater - the name changes to User - 21.56 or less - the name changes to User - the range 21.57 to 21.61 - the name stays as Letter
Confirming Al's findings in comment 4 with Version: 6.0.0.0.alpha0+ Build ID: 9f2a105aa1467224b662980f6d1c4a42e5d8bdfe CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group Let's confirm this bug - if it is a rounding error, then it should be fixed, if it is a UI synchronisation error then that should also be fixed.
If someone could test with earlier versions we might be able to determine whether it is also a regression.
Alex I find the same issue with Version: 5.3.4.2 Build ID: f82d347ccc0be322489bf7da61d7e4ad13fe2ff3 CPU Threads: 4; OS Version: Mac OS X 10.12.6; UI Render: default; Layout Engine: new; Locale: en-CA (en_US.UTF-8); Calc: group Version: 5.2.7.2 Build ID: 2b7f1e640c46ceb28adf43ee075a6e8b8439ed10 CPU Threads: 4; OS Version: Mac OS X 10.12.6; UI Render: default; Locale: en-CA (en_US.UTF-8
On Mac OS X 10.12.6 Using Version: 5.4.1.1 Build ID: a5be49f0c45fe24a575c7f41559aa8fc79a781a2 CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; Locale: en-CA (en_US.UTF-8); Calc: group Changing the Width or the Height size by .01 cm increments for other Paper Formats (eg A4, Legal, Japanese Postcard) one can reproduce the problem.
** 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
This is still reproducible using the steps in the first comment. Version: 6.1.0.3 Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 CPU threads: 8; OS: Mac OS X 10.12.6; UI render: default; Locale: en-CA (en_CA.UTF-8); Calc: group threaded
Bug not reproducible in version Version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded
Dear Andy M, 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
Ok, so this is still present, and also on Windows My native unit is inches, so there's no problem with changing the Letter size But, selecting A4 and changing the height from 11.69 accepts also 11.70 as A4 LO 3.3 only accepts 11.69 as A4, so this would be a regression Version: 6.4.0.3 (x64) Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8 CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
(In reply to eisa01 from comment #13) > But, selecting A4 and changing the height from 11.69 accepts also 11.70 as A4 > > LO 3.3 only accepts 11.69 as A4, so this would be a regression Already seen in the oldest commit of Linux 43all bibisect repo, so can not be bibisected.
I'm a bit puzzled why anyone would care if such a minor difference is size is ignored. In any case, this is intentional, via i18nutil/source/utility/paper.cxx's void PaperInfo::doSloppyFit(bool bAlsoTryRotated) Obviously, requiring overly specific sizes is also problematic. This function was added along with lots of other "stuff" in commit 4a3b7bff01e0e97e88f7718314208c4c7d262276 Author: Ivo Hinkelmann Date: Fri Jun 12 09:36:34 2009 +0000 CWS-TOOLING: integrate CWS unifypaper01
Let's get the opinion of the UX team given comment #15
Following Justin's comment 15 it's by design => NAB (For A4, I can a range of 3mm. With inch the input precision (or the algorithm?) doesn't allow me to modify the size by less 0.01 and I get immediately a user format. MAXSLOPPY is defined as 21, likely TWIPS = 0.37mm/0.01".)