Created attachment 186161 [details] Character Style editing panel, Font & Organizer tabs Hi. I have an issue in creating character styles with a certain body size, with a particular body size with decimal values. I am trying to set it as 10.4 pt, and indeed it looks like it in the “Font” tab from the Character Style editing modal window, but when changing to the main, “Organizer” tab, the font body size appears as being 10.35 pt. I can reproduce this effect with body sizes 10.2 pt (it's converted to 10.15 pt), 10.7 pt (it's converted to 10.65 pt), 10.9 pt (it's converted to 10.85 pt), and so on… Basically, 0.05 pt are being subtracted from any and all decimal values of 0.2, 0.4, 0.7 and 0.9 pt. However, on the Paragraph Style modal window, I can set up whatever decimal values for font body size I wish, and they won't be messed with. This is a problem, as I wish to set a size of 10.4 pt for my default body text paragraph style and be able to set specific character styles inside those paragraphs (such as small caps, emphasis, etc.), and with this bug I'll be getting text that is smaller than it should (it's subtle, but as a typography major and future PhD candidate, it is a big and unacceptable issue). Also, I've tried changing LibreOffice Writer's default measurement units to other settings, such as points, to no avail. Those values are still messed with. Do you have any suggestions on how to coerce LOo Writer to respect those values (maybe by saving those styles into a template/model, and editing that file outside of LOo Writer in a text editor)? I've tried everything, including selecting text with the desired font body size and updating the target style by selecting “Update Selected Style” from the Styles panel drop-down menu, also to no avail. I tried restarting the application, and had changed the UI into English (USA), in order to better write this bug report, and I seem to at least be able to create new styles from selections that seem to respect my choice of font body size. I shall then recreate or edit all styles from scratch (my trick was to recreate the default one, and make all built-in styles inherit its properties), but that doesn't make this any less of a bothersome bug.
Confirmed. But half point sizes are respected/correctly rounded. Looking at the XML in the archive, seem to have a rounding issue. Full point and half point are fine, but other decimal point sizes are not and get a longish float that seems wrong, which gets rounded for display in the UI. Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded =-=-= STR 1. Create new empty Writer document and insert the "dt" -> <F3> text 2. Applying a PS (other than default) Text Body 3. Do a <Ctrl>+F Find and then 'Find All' some repeated word, e.g. "He" 4. From Sidebar <F11> Styles panel, move to the CS tab 5. note it will have 'No Character Style' 6. select a CS, e.g. 'Quotation' it will apply the CS to multiple selection 7. from Sidebar Styles deck on the CS panel, for the active CS (e.g. 'Quotation') open its 'Modify..." dialog and move to the 'Font' tab 8. assign a full point or half-point size and apply 9. check the 'Organize' tab --> result matches the full or half pt 10. back to the 'Font' tab and in its 'Size' list box type a decimal value, e.g. "13.4" and apply. 11. check the 'Organize' tab --> result show an incorrect decimal value. 12. OK out of the CS dialog. 13. Save the document to FODT 15. find the CS and examine the text-properties fo:font-size value =-=-= @Mike, any chance there was more needed for bug 145158 and the rounding in https://gerrit.libreoffice.org/c/core/+/124895 as follow on to https://gerrit.libreoffice.org/c/core/+/110839 unit conversions?
Created attachment 186192 [details] Font set in CS dialog to 13.4 results in 13.3500003814697pt value in XML
Interesting follow-up. Any updates on how hard this might be to fix, and what level of priority is given to this? Thank you in advance!
https://gerrit.libreoffice.org/c/core/+/152894 (In reply to João Gomes from comment #3) > what level of priority is given to this? As with everything in this project: the only existing level of priority is "when a developer appears that is interested in fixing this problem". Usually, regressions are treated with higher priority. But this is not a guarantee of any kind.
(In reply to V Stuart Foote from comment #1) > other decimal point sizes are not and get a longish float that seems wrong "that seems wrong" is ambiguous, allowing to be read as "there are longish representation, and the *value* is wrong - e.g. significantly smaller than expected"; or as "it is wrong that such *longish* representation is used there - it should be shown exactly as in the UI". The problematic value (significantly different from the expected value) should be fixed by the change in comment 4. The "longish" representation itself is not handled; I am unsure if that is a problem at all.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cf0fe26f95b5435d65623165cf7ba381eaa0738a tdf#154349: round before converting to an integer It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Mike Kaganski from comment #5) > (In reply to V Stuart Foote from comment #1) > > other decimal point sizes are not and get a longish float that seems wrong > ... The "longish" representation > itself is not handled; I am unsure if that is a problem at all. FTR: the relevant code is in XMLCharHeightHdl::exportXML (xmloff/source/style/chrhghdl.cxx); we could use rtl_math_round to round the value to 1 decimal (using *double*) - *iif* there is a official limit to 0.1 pt precision, which exist in the UI, but I don't see anything documenting that; but even then, I would fear that that could break some round-trip scenario, where the more fine-grained value comes from another generator, supporting more flexibility. Note that ODF itself does not limit the precision here. And if still wanted, one should create a *separate* issue for this, and copy the code pointer there - this one should be (hopefully) fixed by the commit above.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/7484b1054acd378b94ea4e41a8644fd0e8000ba9 tdf#154349: round before converting to an integer It will be available in 7.6.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/f7e52df2dde0b80f33123790681e94785154d566 tdf#154349: round before converting to an integer It will be available in 7.5.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.