Bug report #12008

wordwrap does not insert custom delimiter anymore

Added by Regis Haubourg almost 10 years ago. Updated over 9 years ago.

Status:Closed
Priority:Severe/Regression
Assignee:-
Category:Expressions
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

Description

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.

History

#1 Updated by Giovanni Manghi almost 10 years ago

  • Priority changed from High to Severe/Regression

#2 Updated by Jürgen Fischer almost 10 years ago

  • Subject changed from wordwrap does not insert custom delimiter no more to wordwrap does not insert custom delimiter anymore

#3 Updated by Martin Dobias over 9 years ago

  • Status changed from Open to Feedback

I am not sure what is your actual problem. Could you please post a sample expression with wordwrap() that exhibits the problem and your expected output (vs real output)?

#4 Updated by Regis Haubourg over 9 years ago

Hi Martin,
before :

wordwrap("myfield", 5, '%') 
> abcde%hijkl%mn..

currently:

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..

Cheers
Régis

#5 Updated by Martin Dobias over 9 years ago

Hi Regis

I have just checked - there is no wordwrap() function in 2.2. It was added in 2.4 and since then it works the same way: the third argument allows the user to specify what delimiter to use instead of space.

#6 Updated by Regis Haubourg over 9 years ago

Ouch, was it in ExpressionPlus plugin before being committed? I remember Nathan having published expressions that way when having missed feature freeze deadline.

#7 Updated by Martin Dobias over 9 years ago

Hmmm no idea... all I know is that wordwrap function was contributed by Mathieu (nirvn).

Can we close this issue?

#8 Updated by Regis Haubourg over 9 years ago

Did someone fixed it?

#9 Updated by Martin Dobias over 9 years ago

Is there anything to fix? The wordwrap() function never worked the way as you indicated as "before" - it always worked like it does now...

#10 Updated by Regis Haubourg over 9 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..

#11 Updated by Nathan Woodrow over 9 years ago

I don't recall it being in Expression+ but I will check now.

#12 Updated by Martin Dobias over 9 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?

Related: http://gis.stackexchange.com/questions/30084/how-to-create-multiline-labels-in-qgis

#13 Updated by Mathieu Pellerin - nIRV over 9 years ago

Regis, I'm the one who implemented the expression engine's wordwrap() function.

The only function variables I implemented were the following:
wordwrap(string_to_wrap,nb_to_wrap,character_to_wrap)

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.

#14 Updated by Regis Haubourg over 9 years ago

  • Status changed from Feedback to Closed

Ok, apologies for not understanding the doc OK. I wasn't aware of such invisible space characters, we should explain that in the doc string. Closing the ticket now.

Also available in: Atom PDF