Created attachment 166376 [details] screenshot of the issue SUMMARY Probably the character is taller than expected? But it completely break's Dolphin's rendering of the text, and not just right around the unexpected character. STEPS TO REPRODUCE 1. `touch 'this is some text⧸this is some text.txt'` 2. Look at the resulting file in Dolphin. Note that the character above is not a slash, it's U+29F8. OBSERVED RESULT Broken text rendering - see screenshot. Affects both thumbnail view and details view. The font shown here is Source Sans 3 11 pt. EXPECTED RESULT No broken text. Specifically, text that is too tall for the box should just overflow it (or be cut off), without changing the line width. (Even if changing the line width were reasonable, something has clearly gone badly wrong in this case.) SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.7.6-arch1-1 (64-bit) Graphics Platform: Wayland
Created attachment 166379 [details] things seems to work on my end Can't reproduce on arch linux, wayland, source build of dolphin
I see this with a source build as well, built just now on latest: https://invent.kde.org/system/dolphin/-/tree/6231e67120cf4abae696b736e9d851464338f4dd It's possible that the height of the character in my font is triggering the issue.
This appears to be an issue with the fallback font used, which was Minion Math v1.026. Looking at the font metrics in FontForge, it seems the OS/2 line height is something absurd. Apparently, when Qt renders a text string that includes fallback fonts, it changes the line height to be the maximum line height of any font used in the string. Gtk appears to clip to whatever line height is used by the default font for the text string (though I haven't tested this closely). Note that the size of the glyph was a complete red herring in this case. This definitely isn't a Dolphin specific issue, and I'm not sure it's really any issue with Qt either. Closing.