Bug report #4442

Multi line labels render on one line with curved labels

Added by Nathan Woodrow over 12 years ago. Updated about 5 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Labelling
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:end of life
Crashes QGIS or corrupts data:No Copied to github as #:14374

Description

If you have a multi line label and use curved labeling the label will be rendered on one line ignoring the multi line setting.

See attached pictures for details.

AfterCurved.png - Using curved labels (37.6 KB) Nathan Woodrow, 2011-10-25 04:02 PM

BeforeCurved.png - Using parallel setting (49.7 KB) Nathan Woodrow, 2011-10-25 04:02 PM

multiline-offset-comp.png (140 KB) Larry Shaffer, 2012-11-17 01:00 PM

History

#1 Updated by Martin Dobias over 12 years ago

The curved placement is not really meant to draw multiline labels: each character of the text is rotated to have baseline parallel to the line. The multiline option should be probably disabled for this method.

#2 Updated by Giovanni Manghi over 12 years ago

  • Target version set to Version 1.7.4

#3 Updated by Paolo Cavallini over 12 years ago

  • Category changed from Map Canvas to Labelling
  • Affected QGIS version set to master
  • Crashes QGIS or corrupts data set to No

#4 Updated by Paolo Cavallini about 12 years ago

  • Target version changed from Version 1.7.4 to Version 1.8.0

#5 Updated by Paolo Cavallini over 11 years ago

  • Target version changed from Version 1.8.0 to Version 2.0.0

#6 Updated by Anita Graser over 11 years ago

  • Priority changed from Normal to Severe/Regression

#7 Updated by Larry Shaffer over 11 years ago

Setting this issue to blocker without any discussion about the difficulty of implementation, and how that relates to the limited amount of time until the current feature freeze, is premature. I've set it to High.

Like Martin mentioned, PAL is just not designed to support this. My opinion is for the multiline options be disabled when curved placement is selected for v. 2.0, and implementation of this be moved to v. 2.1; but, only after other issues with curved labels are addressed, possibly offering a simpler means of supporting a multiline option.

I very much would like to have this feature as well, and have looked at many methods to do so. There are issues with implementing this, with regards to how PAL creates/handles curved labels, though I may have a solution.

PAL Issues

  • Curvature offset - [see multiline-offset-comp.png] There are two approaches to offsetting the above/below lines in a multiline label, relative to the base line that PAL would create normally for one line: I refer to them as shifted and scaled in the png. An ideal implementation would use scaled, where the inside of curves are reduced on 'below' lines and expanded on 'above' lines. Unfortunately, until the issue with PAL not showing enough curved labels is fixed, this could result in label lines with tighter curves not showing up. If the whole label is to not be shown under that circumstance, then the tightest curve becomes a limiting factor. If the shifted approached is used, only one line in a multiline label will actually appear to follow a curve, and above/below lines may awkwardly intersect or overlap the underlying feature.
  • Text alignment of offset - [see multiline-offset-comp.png] As you can see in the attachment, even small identical features that are manually offset via shifted or scaled methods do not exhibit consistent horizontal text alignment when output from PAL. There is currently no support in PAL for 'pinning' candidates to a particular point on a line (though I have an idea for that, see below).
  • Number of lines - While ostensibly unrelated, supporting even-numbered multilines would mean also adding support to PAL for per-label distance offset (currently only per-layer is supported).

Some solutions

  • My best solution so far - I have another idea for a feature I call 'label anchors' that could help with this. The defined anchor would tell PAL to only use one candidate and where it starts. (This is different than data defined x/y, which totally skips chosen placement algorithms and essentially treats the geometry as a point.) Then, the following could possibly be implemented:
    • Figure what the widest text line of a multiline label is and send it PAL as a single-line curved label.
    • Tag that label when sending into PAL as having above/below lines.
    • Adjust the height fontmetrics for the individual characters of that single line label to be similar to the final multiline label (so resultant label footprint can be part collision calculation).
    • After PAL solution, when labels are drawn, catch tagged multiline labels. Those labels are not drawn and are removed from list. Before removal, new geometries are generated based upon number of lines, offset according to their line height setting, and with geometry based upon the baseline of the single-line characters (or possibly a clipping from original geometry). Each new geometry is assigned the appropriate text relative to its line, and a calculated 'anchor' point that equates to its starting point according to how that text would be aligned relative to other lines (left, center, right).
    • After completion of drawing all other labels, a new PAL layer is created and the multiline geometries are registered with PAL. PAL is then solved for that single layer, which should produce labels correctly anchored to the provided line geometries.
    • Layer rendering execution is then, finally, returned back to vector layer.
    • (A similar approach can be used to create more generalized/simplified curved labels, offset from complex line features.)
  • Qt implementation - It's possible to create text on a path with Qt. While this might allow handling of multilined labels outside of PAL, it would not afford collision resolution.

#8 Updated by Giovanni Manghi over 11 years ago

  • Priority changed from High to Normal

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

  • Target version changed from Version 2.0.0 to Future Release - Lower Priority

#10 Updated by Hugo Mercier almost 8 years ago

I am considering a "simplification" of the QEP 29 (https://github.com/qgis/QGIS-Enhancement-Proposals/issues/48) that will add multi line support for curved labels.

@Larry, thanks for your explanations here. Some questions:

- "Unfortunately, until the issue with PAL not showing enough curved labels is fixed, this could result in label lines with tighter curves not showing up" : is this issue still there in a recent master ? If yes, what would be the solution ?

- "The defined anchor would tell PAL to only use one candidate and where it starts. (This is different than data defined x/y, which totally skips chosen placement algorithms and essentially treats the geometry as a point.)" Couldn't data defined x/y positions be treated as an anchor point ?

I still have to reread your proposed solution to be sure I understand :)

#11 Updated by Hugo Mercier almost 8 years ago

Hmmm I've just realized an anchor point would be actually a point on the curve (not an arbitrary x/y point), correct ?
That could optionnaly be given by the user by a number that is a "curved abscissa" on the curve, right ?

#12 Updated by Regis Haubourg almost 8 years ago

Hugo Mercier wrote:

- "Unfortunately, until the issue with PAL not showing enough curved labels is fixed, this could result in label lines with tighter curves not showing up" : is this issue still there in a recent master ? If yes, what would be the solution ?

Hi, it is better now that user can choose angles settings between letters before label is skipped. Anyway, curved labels are skipped in many cases when unzooming, only generalizing - smoothing on the fly geometries before sending them to PAL could help. It might be easier now that work on geometry generator has been made.

#13 Updated by Regis Haubourg almost 8 years ago

Hugo Mercier wrote:

Hmmm I've just realized an anchor point would be actually a point on the curve (not an arbitrary x/y point), correct ?
That could optionnaly be given by the user by a number that is a "curved abscissa" on the curve, right ?

A numeric value is not an option from a user point of view. We should try to find it using some kind of st_LineLocatePoint function.
We could imagine such a workflow with auxiliary data to store anchor points :

- automatic curved label placement finds candidates and skip some labels (letters overlap, obstacles, priorities between layers)
- when the user activates "move label" tools, with underlying XY editable fields correctly set in data defined properties, then anchor point and bounding box of each label is displayed. Skipped labels should then be displayed, uncurved, anchored at the middle of the line, maybe greyed out to point out that this place is not suitable for curved labeling.
- dragging a label to another place will do the lineLocatPoint (or snapping) thing to get the new anchor point, projected on the line. That new XY will be stored in data fields and the solution designed by Larry can be deployed to diplay the curved label to a custom location.

#14 Updated by Giovanni Manghi almost 7 years ago

  • Regression? set to No
  • Easy fix? set to No

#15 Updated by Giovanni Manghi about 5 years ago

  • Resolution set to end of life
  • Status changed from Open to Closed

Also available in: Atom PDF