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