Version: unspecified (using Devel) OS: Linux When browsing files with Dolphin, some file names are abbreviated. This may be a nice feature sometimes, however, it is often counter intuitive when file names are shorted. It is not clear what criteria are determining if a file name should be shorted. For example, I have a folder with the following folders: "Yeah-Yeah-Yeahs" and "Wolfgang-Amadeus-Mozart". For some reason "Yeah-Yeah-Yeahs" is abbreviated to "Yeah-Yeah-Yea...", but "Wolfgang-Amadeus-Mozart" -- which is a longer file name -- is not. It is counter intuitive that: 1: Yeah-Yeah-Yeahs (15 chars) is abbreviated when Wolfgang-Amadeus-Mozart (23 chars) is not. 2: Yeah-Yeah-Yeahs (15 chars) is abbreviated to "Yeah-Yeah-Yea..." (16 chars), which is longer than the original name. I have attached screen shot that illustrates the problem. Reproducible: Always
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. ***