Description: The Combining enclosing keycap (Unicode: U+20E3) used in text ist not displayed correct. It's spacing is off so that it is overlapping with the text next to it. Also it is not displayed at all, if it is bold. The problem seems to be related to the used font. I found the problem in Sgeoe UI, while Arial seems to work. The sample file was created using MS-Word. Steps to Reproduce: 1. Create a document in MS-Word 2. Insert a text using Combining enclosing keycap 3. Change the font to Segoe UI 4. Open the document in LibreOffice Writer Actual Results: Actual (LibreOffice Writer).png Expected Results: Expected (MS-Word).png Reproducible: Always User Profile Reset: Yes Additional Info: The file I used for testing is also attached.
Created attachment 197934 [details] File to reproduce the issue
Created attachment 197935 [details] Actual Display of the text in Writer
Created attachment 197936 [details] Expected Display of the text (ms-Word)
I tested your attachment, but I was not able to reproduce the bug. LO is showing normal behavior. Version: 24.8.3.2 (AARCH64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 8; OS: macOS 14.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 197943 [details] screenshot
Confirm with Version: 24.8.3.2 (X86_64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Created attachment 198035 [details] Commit log of bibisected range Bibisected with win32-4.3, but it threw up a range. The hashes don't seem to be in order, so I won't link to a Gitiles range query. Instead, I'm attaching the source commit log and a list of hashes as separate text files. I used Windows because it comes with Segoe UI font. On Linux with a substituted font it looked bad even in the oldest of the 4.3 bibisect repo.
Created attachment 198038 [details] List of hashes from bisect
U+20E3 is a Nonespacing Mark, so it is supposed to combine with the previous character. This is what is causing the spacing. I don’t understand what is the intended use here, but if it is a spacing white box, then this is the wrong character. May be use something like U+2610, U+25A1, or U+25A2. U+20E3 is meant to simulate keyboard buttons, i.e. A⃣ to simulate “A” button. I don’t know why Microsoft Word makes it a spacing symbol, but this does not seem to be Unicode-complaint. IMHO, should be close as NOTABUG, unless Microsoft-compatibility here is considered important (and then it would need deeper research on why and when Microsoft does this, and a comparability flag).
I think I did not completely understand the idea of U+20E3 at the time. I agree with Khaled, that the character is designed to enclose the previous character. Therefore, the way writer is displaying the character is better than Word does. As far as I can see Segoe UI bold does not contain the character and MS Word instead is displaying the notdef Glyph. If the not bold character is used the behavior of MS Word is similar to Writer. I can see arguments for both behaviors and would not consider any of them a bug. I also see no need for Microsoft-compatibility in this situation and therefore close the bug.
Could also assign a font with coverage of the combining glyphs and text strings. Metrics for combining keys from "Noto Sans Symbols 2" seems to work well. Or you could just use a font styled with keycaps like "Libertinus Keyboard". Either way => NAB.