Summary: | File name abbreviations are counter intuitive | ||
---|---|---|---|
Product: | [Applications] dolphin | Reporter: | Thomas Damgaard <thomasdn> |
Component: | general | Assignee: | Peter Penz <peter.penz19> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | frank78ac, fredrik, simon.eu |
Priority: | NOR | ||
Version: | 16.12.2 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 4.5.2 | |
Sentry Crash Report: | |||
Attachments: |
screendump
Font settings that make the bug reproduceable for me Simple Qt-only test case |
Description
Thomas Damgaard
2010-09-13 16:44:14 UTC
Created attachment 51603 [details]
screendump
Created attachment 51615 [details]
Font settings that make the bug reproduceable for me
Thanks for the bug report! I can reproduce the issue in trunk. I've attached my font settings (because this kind of bug is usually very sensitive to the font).
The issue is similar to bug 183620: In KFileItemDelegate::Private::layoutText(...), size.width() is larger than constraints.width(), leading to the unnecessary eliding. I haven't figured out yet what goes wrong with the width calculation though. I think I got a bit closer to the solution: It seems that the width calculation in Dolphin and the actual display of the file name in KFileItemDelegate do *not* use the same QString. In the string that is used by KFID, an invisible character is inserted after each "-" in Yeah-Yeah-Yeahs, namely QChar(8203). The result is that the modified string needs a bit more horizontal space, leading to the abbreviation. Adding this character to the string happens in KFileItemDelegate::Private::display(...) which calls KStringHandler::preProcessWrap(const QString&). According to the API docs, that function adds "Zero-width space characters in the string at points that wouldn't normally be considered word boundaries by QTextLayout, but where wrapping the text will produce good results." The problem seems to be that the width of these characters is not zero as it should be. Created attachment 51751 [details]
Simple Qt-only test case
Seems to be a Qt issue - in the font "DejaVu Sans" (and maybe others), the "Zero Width Space" character QChar(0x200b) does not have zero width if it is between a "-" and a "Y".
Unfortunately, the reproduciblity depends on the font :-( I'll try to analyse this a bit further when I find some time before I report this upstream.
It's not quite as I said in my previous comment - the "Zero Width Space" character does have zero width (just as it should), but it prevents the kerning of "-" and "Y". If I disable font kerning, the bug is gone. @Fredrik, Peter: I'm a bit unsure about this bug. The short version is: KFID adds Zero Width Spaces to the file name to indicate wrapping positions. These spaces prevent kerning (in the present case, the space between "-" and "Y"), thus increasing the width required to render the text. Because the text does not fit into the space that is calculated in DolphinFileItemDelegate (which does not add the Zero Width Spaces to the text before its width is evaluated), it is elided. So the question is: Should kerning occur even for two characters which have a Zero Width Space in between? In that case, it would be a Qt bug. Or is it OK not to do kerning in such cases? Then we should try to fix this in a different way (e.g., use KStringHandler::preProcessWrap(...) also in DolphinFileItemDelegate for the width calculation). I tend to think that the second option is right... @Frank: Wow, thanks for your analyses, I guess this was quite time-consuming. I tend to agree that don't doing any kerning seems to be OK if there is a zero width space in between. So I think we should try to fix this in DolphinFileItemDelegate as you propose :-/ SVN commit 1179568 by freininghaus: Use KStringHandler::preProcessWrap() when calculating the width of a file name in DolphinFileItemDelegate. This makes sure that zero width spaces (which prevent kerning) are added at the same places where KFileItemDelegate adds them when actually rendering the name. Fixes the problem that file names are elided and partly replaced by "..." even though there is enough space for the full name. CCBUG: 251121 M +2 -1 dolphinfileitemdelegate.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1179568 SVN commit 1179569 by freininghaus: Use KStringHandler::preProcessWrap() when calculating the width of a file name in DolphinFileItemDelegate. This makes sure that zero width spaces (which prevent kerning) are added at the same places where KFileItemDelegate adds them when actually rendering the name. Fixes the problem that file names are elided and partly replaced by "..." even though there is enough space for the full name. BUG: 251121 FIXED-IN: 4.5.2 M +2 -1 dolphinfileitemdelegate.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1179569 *** Bug 260691 has been marked as a duplicate of this bug. *** |