large number of tolerance pixels in tests
The previous reference images all used such a narrow reference font
that they required a very large pixel tolerance, which was letting
through real errors.
As a result disable the json opacity test, which was completely
broken ever since it was introduced. The test had a LARGER number
of tolerance pixels than the reference images had, and accordingly
was testing nothing at all. And the issue hasn't been fixed, so
the test was a false positive... Now the test is fixed but failing
and disabled, pending someone (else) fixing the underlying issue.
This PR fixes the issue that when restoring a numeric scale bar layout item from an XML (such as when opening a saved project or pasting a copied item) the height of the scale bar layout item is set to a value larger than the one stored in the XML (see #26931 and #32379).
The issue arises from the fact that restoring a scale bar layout item initially creates a QgsLayoutItemScaleBar with the default style of Single Box, which has larger minimum dimensions as calculated by calculateBoxSize. The call to attemptResize in QgsLayoutItem::readXml, which tries to apply the dimensions stored in the XML, cannot set the dimensions of the scale bar layout item to be smaller than these minimum dimensions, so the dimensions are only applied correctly if they happen to be larger.
To fix this issue, this PR re-applies the stored size by calling attemptResize in QgsLayoutItemScaleBar::readPropertiesFromElement after the scale bar style has been set.
Additionally, the width of the numeric scale bar was not restored correctly because QgsLayoutItemScaleBar::finalizeRestoreFromXml calls QgsLayoutItemScaleBar::updateScale, which calls resizeToMinimumWidth(). This PR adds a check to skip resizeToMinimumWidth when the style is Numeric.
Fixes#26931, fixes#32379
This allows users to (optionally!) customise the symbol appearance
for a legend node, e.g. to tweak the colors or symbol sizes to better
provide a "representative" patch symbol compared with how those
corresponding features actually appear on the map.
It's useful for exaggerating symbol widths, or for manually tweaking
the colors of semi-transparent symbols so that the colors represent
the actual appearance of the symbols when rendered on top of the map
content. Or to tweak the marker interval/offset in marker lines so that the
markers are nicely spaced in the legend patch.
Fixes#14077
This refactors and completes the recently added work on random number raster layer creation algorithms (see #35835) and reworks the single algorithm implementation proposed in #36065 to a base-algorithm solution which avoids duplicate code.
With the new algorithms aimed towards distribution based random number creation, QGIS reaches to the same level of functionality as current ArcGIS random raster creation tools. In total, the PR adds the following algorithms (normal and uniform raster layer creation algs are refactored to be in line the new naming scheme):
Create random raster layer (binomial distribution)
Create random raster layer (exponential distribution)
Create random raster layer (gamma distribution)
Create random raster layer (negative binomial distribution)
Create random raster layer (normal distribution)
Create random raster layer (poisson distribution)
Create random raster layer (uniform distribution)
polygons
Options are:
- 'yes': allow placing outside the polygon if needed
- 'no': don't allow outside placements
- 'force': only ever put this label outside the polygon
outside of polygon features when required
When a label can't be placed inside the polygon and this option is checked,
then it will be automatically placed at a nicely selected location
just outside of the polygon
Sponsored by QGIS Swiss user group!
outside of polygon features
Based on a tweaked version of the logic presented by Rylov & Reimer
from "A practical algorithm for the external annotation of area features" (2016),
this placement mode generates a set of label candidates which sit at a
set distance outside of a polygon's exterior ring.
Designed for candidate generation for small polygons wrt label size, or in
other cases where it's not possible or desirable to fit the label inside
the polygon features itself
