Bug 251121 - File name abbreviations are counter intuitive
Summary: File name abbreviations are counter intuitive
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 16.12.2
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Peter Penz
URL:
Keywords:
: 260691 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-09-13 16:44 UTC by Thomas Damgaard
Modified: 2010-12-19 18:53 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.5.2
Sentry Crash Report:


Attachments
screendump (8.15 KB, image/png)
2010-09-13 16:44 UTC, Thomas Damgaard
Details
Font settings that make the bug reproduceable for me (123.44 KB, image/png)
2010-09-13 22:22 UTC, Frank Reininghaus
Details
Simple Qt-only test case (774 bytes, text/plain)
2010-09-17 12:34 UTC, Frank Reininghaus
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Damgaard 2010-09-13 16:44:14 UTC
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
Comment 1 Thomas Damgaard 2010-09-13 16:44:41 UTC
Created attachment 51603 [details]
screendump
Comment 2 Frank Reininghaus 2010-09-13 22:22:36 UTC
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).
Comment 3 Frank Reininghaus 2010-09-14 18:19:52 UTC
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.
Comment 4 Frank Reininghaus 2010-09-17 11:25:26 UTC
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.
Comment 5 Frank Reininghaus 2010-09-17 12:34:55 UTC
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.
Comment 6 Frank Reininghaus 2010-09-17 16:03:25 UTC
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.
Comment 7 Frank Reininghaus 2010-09-18 11:10:04 UTC
@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...
Comment 8 Peter Penz 2010-09-23 11:36:46 UTC
@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 :-/
Comment 9 Frank Reininghaus 2010-09-25 23:54:42 UTC
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
Comment 10 Frank Reininghaus 2010-09-25 23:56:57 UTC
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
Comment 11 Frank Reininghaus 2010-12-19 18:53:49 UTC
*** Bug 260691 has been marked as a duplicate of this bug. ***