Bug report #12008
wordwrap does not insert custom delimiter anymore
|Affected QGIS version:||2.6.0||Regression?:||No|
|Operating System:||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||20211|
This is a regression from 2.2, using a custom delimiter does not work, when using default \\░n option works OK.
This is useful for generating legend carriage return in unique values renderer, where \
is not interpreted in legend and composer's legend.
#4 Updated by Regis Haubourg over 4 years ago
wordwrap("myfield", 5, '%') > abcde%hijkl%mn..
wordwrap("myfield", 5, '%') > abcdehijklmn..
while this still works for implicit carriage return if no delimiter is given in third parameter.
wordwrap("myfield", 5) > abcde > hijkl > mn..
So, third parameter option is broken, and this prevents using the carriage return on a special character option of labeling. We break compatibility with old projects using that also..
#10 Updated by Regis Haubourg over 4 years ago
???? I don't get the point here. You are free to put it back from blocker to lower priority if you judge it's not a regression, but please don't close a ticket when feature is not doing what doc is telling is does!
I'm pretty sure it as worked as described once, since I built production labeling with it and is broken now, but I can make mistake on that, and won't reinstall older versions to check it.
I didn't mark it as blocker myself. Could we calm down please? Everyone is trying to help here..
#12 Updated by Martin Dobias over 4 years ago
Regis, apologies if my comments felt harsh - they were meant to be in completely neutral tone.
I am only trying to understand what exactly is going wrong as from my point of view things work as they were supposed to - there are even tests for wordwrap() that confirm the current behavior is correct.
In your latest comment you mention that wordwrap is not doing what doc is telling it does. I guess you refer to the function help and the documentation of the last argument:
delimiter_string → is string. The delimiter string to wrap to a new line (optional).
Although the documentation is not very descriptive, it indicates that the delimiter_string may be changed to a new line. The rationale was that in some non-latin scripts they use different characters than just the space to separate words - this extra argument allows the user to specify such delimiter.
I am not sure how it is possible you used wordwrap() with different semantics. Could you please verify your 2.2 installation?
#13 Updated by Mathieu Pellerin - nIRV over 4 years ago
Regis, I'm the one who implemented the expression engine's wordwrap() function.
The only function variables I implemented were the following:
The third function variable, character_to_wrap, is used for the users to set a char that can trigger wrap (by default, it's a space character). It's there for non-Latin based languages to be able to wrap on different characters (such as invisible-space for Indic languages).
What your referring to, i.e. to have a custom character to use instead of \
, was never implemented. It could be implemented as a fourth variable if someone has a need for it. But it's definitively not a regression. It'd have to be filed as a feature request.
Also, a wordwrap('abcdefghij',5) would return 'abcdefghij' as the implementation requires the presence of a space (or a customized character_to_wrap) to wrap. That has always been the way the function has worked, since its addition in QGIS 2.4.