(only works with Cartographic point label placement). When this
setting is active, the label distance applies from the bounds
of the rendered symbol for a point, instead of the point itself.
It's especially useful when the symbol size isn't fixed, eg if
it's set by a data defined size or when using different symbols
in a categorised renderer.
Sponsored by Andreas Neumann
A new control for setting a label's "z-index" has been added to
the labeling properties dialog. This control (which also accepts
data-defined overrides for individual features) determines the order
in which label are rendered. Label layers with a higher z-index
are rendered on top of labels from a layer with lower z-index.
Additionally, the logic has been tweaks so that if 2 labels have
matching z-indexes, then:
- if they are from the same layer, a smaller label will be drawn
above a larger label
- if they are from different layers, the labels will be drawn in
the same order as the layers themselves (ie respecting the order
set in the legend)
Diagrams can also have their z-index set (but not data defined)
so that the order of labels and diagrams can be controlled.
Note that this does *NOT* allow labels to be drawn below the
features from other layers, it just controls the order in which
labels are drawn on top of all the layer's features.
Fix#13888, #13559
Now all classes and members are either exposed to bindings or marked
as "not available in Python bindings" in the docs.
Drop test thresholds to 0. Now it should be much easier to determine
what missing members have been added which are causing test
failures.
Rationale:
- there was a lot of large objects passed by value, so potentially
there's a speed bump from this
- even for implicitly shared classes like QString/QList there's still
a (small) cost for copying the objects when there's no reason to
- it's the right thing to do!
The writing of data-defined properties to XML was using invalid data.
Also fixes a possible memory leak in assignment operator.
Thanks Nyall for help tracking it down!
This code has been funded by Tuscany Region (Italy) - SITA (CIG: 63526840AE) and commissioned to Gis3W s.a.s.
- QgsPalLabeling now internally uses new engine
- label/diagram providers can hook into rendering loop to avoid extra feature loops
- map rendering uses the new engine instead of QgsPalLabeling
This code has been funded by Tuscany Region (Italy) - SITA (CIG: 63526840AE) and commissioned to Gis3W s.a.s.
Allows you to make labels prefer to overlap features from certain
layers rather than others. Can also be data defined, so that certain
features are more likely to be covered than others.
act as obstacles
Options are either avoid placing labels over polygon interior
or avoid placing over polygon boundaries. (Previous behaviour
was always avoid placing over interior).
Avoiding placing over boundaries is useful for regional boundary
layers, where the features cover an entire area. In this case
it's impossible to avoid placing labels within these features,
and it looks much better to avoid placing them over the boundaries
between features. End result is better cartographic placement of
labels in this situation.
This allows users to set a layer as just an obstacle for other
layer's labels without rendering any labels of its own.
Ideas for UI improvements are welcome!
When set to this mode, text alignment for labels will be dependant
on the final placement of the label relative to the point. Eg, if
the label is placed to the left of the point then the label will
be right aligned, and if it is placed to the right of the point
then the label will be left aligned.
(fix#11153)
* tree view and attribute selection for layer assigment in dialog
* support fill polygons/HATCH
* represent texts as MTEXT instead of TEXT (including font, slant and weight)
* support for RGB colors when there's no exact color match
* use AutoCAD 2000 DXF (R15) instead of R12
* remove R18 test methods
Funded-By: City of Uster
Funded-By: Ville de Morges
Funded-By: SIGE
- Add labeling engine option to render text-as-text
- Default is still text-as-outlines (vectorized), due to differences between text (as text) and buffer (as outline) methods
- Good output with printing to PDF (searchable, selectable text and embedded fonts)
- OK output with SVG, but differences between text (as text) and buffer (as outline) methods
Does not yet include unit tests or auto-setting of text-as-text for SVG output
