Description: If I write a " " (U+00A0, NON-BREAKING SPACE) in LibreOffice Writer, select it, and make it Italic, it will get slightly wider. The behavior isn't replicated for a normal space, and seems to be a bug, as when this same character is also underlined, the underline stays the width of the non-italic character, causing it to be slightly shorter. This is actually mostly noticeable when underlined italic text contains this character, as it breaks the underline in a fairly noticeable way. Steps to Reproduce: 1.Type a U+00A0 in Writer 2.Select the U+00A0 character 3.Click the "italicize" button, or press Ctrl+I 4.Observe the width of the selection (and therefore, the width of the character) Actual Results: The width of the selection (and therefore, the width of the character) increases. Expected Results: The width of the selection (and therefore, the width of the character) should stay the same, as this is the behavior of a normal space (U+0020). Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version : 6.4.6.2 Build ID : 6.4.6-2 Threads CPU : 4; OS : Linux 5.8; UI Render : GL; VCL: kf5; Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded (running KDE Plasma on Manjaro Linux, was also reproducable with OpenGL disabled) This was marked as a Writer bug because I couldn't reproduce the issue in Draw or Calc.
I was able to reproduce this behavior on my Arch Linux machine on 7.0.3.1: Version: 7.0.3.1 Build ID: 00(Build:1) CPU threads: 16; OS: Linux 5.9; UI render: default; VCL: kf5 Locale: fr-FR (fr_FR.UTF8); Langue IHM : fr-FR 7.0.3-2 Calc: threaded
Created attachment 167211 [details] Sample document with Liberation Serif font Reproduced with 7.1.0 alpha1: Version: 7.1.0.0.alpha1 (x64) Build ID: 987671387712c4f9061d6216ff2f001a7bb9e57b CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); UI: en-US Calc: threaded
Although I can reproduce the described behavior, I'm not really convinced that characters have different width after being italicized is a bug by itself -- after all, as can be seen in the sample document, many other letters have different width with upright and italic forms, too. It is, of course, understandable that users would expect non-breaking spaces to behave the same way as ordinary spaces on this issue. The "broken underline" thing, however, is definitely a bug, therefore setting to NEW.
Not in: Version: 6.0.6.0.0+ Build ID: c30963b8b4bbbe42a24b97aafa161eff9d7ccdd4 CPU threads: 16; OS: Windows 10.0; UI render: GL; Locale: de-DE (de_DE); Calc: CL But in: Version: 6.1.0.1 (x64) Build-ID: 378e26bd4f22a135cef5fa17afd5d4171d8da21a CPU-Threads: 16; BS: Windows 10.0; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL
57746b59ac105b93db876ee352cdd444816af54a is the first bad commit commit 57746b59ac105b93db876ee352cdd444816af54a Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Fri Apr 20 10:58:49 2018 -0700 source 0be3db28a4db4d2c81a5cb2edd48711eec55b51b source 0be3db28a4db4d2c81a5cb2edd48711eec55b51b instdir/program/swlo.dll | Bin 14190080 -> 14190080 bytes instdir/program/version.ini | 2 +- 2 files changed, 1 insertion(+), 1 deletion(-) https://gerrit.libreoffice.org/c/core/+/49972
Sigh, seems both 1c1747ac13a9d895df0fcba2fbb1bd266dccd74b and 0be3db28a4db4d2c81a5cb2edd48711eec55b51b were wrong ... The first one needs some change to avoid the regression that needed the second.
Also in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a34dcd03254480927c403d904c0e754802d97b90 CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Dear zeGolem, 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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug