GNOME Bugzilla – Bug 323711
Allow overriding/tailoring the line-breaking algorithm per pango context or layout
Last modified: 2018-05-22 12:13:10 UTC
Bug 300790 wants Nautilus to wrap after '_' characters. The whole wrapping code seems to take place in Pango, though. In my opinion, in PANGO_WRAP_WORD_CHAR mode, layouts should preferably be wrapped at '_' positions. '.' seems to be preferred alreay.
For the record, here[1] is an email I sent to pango list to ask for some info on how to solve this bug... [1] http://mail.gnome.org/archives/gtk-i18n-list/2005-November/msg00026.html
This is hard to implement, if not impossible. The reason is that Pango implements the Unicode line-breaking algorithm straight. And that's what it does, which is in fact not quite wrong. Underscore behaves exactly like an alphanumeric character in most usecases. You can get the effect you want by inserting Zero-Width Space characters at places that you want a break to happen.
Created attachment 55865 [details] [review] Proposed Nautilus patch (doesn't work) Thanks for your feedback! Maybe you could tell me why the attached patch still makes Nautilus break like thisisfoo.b ar Maybe I'm using the wrong character?
I can't test the patch right now, but having a look at it, I wonder if you lack a : p += strlen(ZERO_WIDTH_SPACE); just after the : p = strcpy (p, ZERO_WIDTH_SPACE);
Yeah, what Nelson said :). You can also use a GString here. That may even qualify for a glib function, like g_utf8_collate_key_for_filename did.
I have no idea how Nautilus works, but obviously you don't want the inserted character to show up anytime when editing the file name. That becomes a bit tricky...
Nelson: odd, according to string.h, stcpy "return(s) the address of the terminating '\0' in DEST". According to man stcpy, "(t)he strcpy() and strncpy() functions return a pointer to the destination string dest.", so the right solution is probably to not use the return value at all and use the += method demanded by you. However, even more odd is that strlen (ZERO_WIDTH_SPACE) returns zero.
Created attachment 55869 [details] strlen proof-of-concept
It's "\xE2\x80\x8B" in C, not "\0xE2\0x80\0x8B".
Yes, that's what the C gurus on freenode.net told me. Thanks for also pointing it out. I keep forgetting about these MBCs. They also claimed that strcpy probably returns a pointer to the first char, and that string.h header docs are useless :P. Thanks for your efforts, it seems to work over here and I'll attach the patch at the other bug report. The editing widget will not break at the same positions, btw.
Yeah, that may be a bit annoying. You press F2 to edit and the line-breakings change.
So you think we should also use the same rules for editing, and afterwards filter out the zero width characters again? May they occur in filenames at all?
That doesn't quite work, since users will be able to move cursor around and otherwise edit those characters, which is not what we really want. We do need a mechanism to tailor line-breaking I'm afraid. Maybe leaving this bug open is a good idea. The idea is you provide a line-breaking function to Pango, which is used instead of the default one. In yours, you can call the original one, then modify the bits to break on _ and .
Behdad, I think you mean: PangoLayout text -> append zero width chars in text for _ and . -> call default break function with text -> remove from the returned text the zero width chars we inserted before -> pangolayout text now has text breaked in _ and . Is this correct?
No, not quite. That's indeed one way this can be done, but a really hard one, since you have to copy the string, etc... You just pass string to default break function, then go over the string and for each . and _ found, you change the can_break attribute of that position to TRUE.
*** Bug 620235 has been marked as a duplicate of this bug. ***
*** Bug 614371 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pango/issues/33.