Looks like there's a label in the test which is placed right on the
boundary of the map, so the geos changes in c7b9fa have shifted it
slightly off the canvas and resulted in it not being drawn.
Update test mask images so this label is optional.
I'm not sure what sip voodoo is preventing the bindings from
calling methods in the base class, so for QGIS <3.0 I've aliased
all the new signatures and will rename them back for 3.0
Note that this doesn't seem to be actually utilised by any
of the preinstalled gradients, but if users have created
a gradient with info then clicking the button would have
crashed QGIS.
Identified by clazy.
default value is non 0
using the monstrosity:
zerowidth='!0'; grep -R -rl -P "\"param\(outline-width\) (?${zerowidth})(.*?)\"" | xargs sed -i -b 's/\(param(outline-width)\)[^"]*"/\1\"/g'
(fix#10908)
* fieldNameIndex: resort to case-insensitive lookup only if
case-sensitive lookup has no match
* file writer: fix handling of fields that only differ by case
reset the fill/border color and border width when changing svg
marker/svg fill SVG files
This change makes the behaviour consistent between the svg marker
symbol and the other marker symbols. Additionally, svg files
which have customisable colors and NO default values set will
be shaded in gray fill/black outline in the svg selector widget,
to follow the same behaviour as the other marker symbol selectors.
Note that this change has NO EFFECT unless the svg files are
modified to remove the default param value, so there will be no
change for users' custom symbols. A follow up commit will need
to remove the default param values from the preinstalled SVG
files though. If you want to test in the meantime, I've modified
just the first two symbols in the accomodation group to make
this change for testing.
(refs #10908)
that sometimes advanced digitising tools would be activated
unexpectedly.
(Coverity... I'm disappointed. Stop slacking off! I've fixed 1000s
of these warnings you flagged yet you missed the ones which trigerred
actual real bugs)
SVG outline width sizes were not correctly calculated, and were
set to a constant value regardless of the rendered size of the svg
image. This meant that:
1. the rendered outline width was effectively randomly scaled
2. the width would change as the symbol size was modified
This change has some large flow on effects, eg:
- the large outline widths required to render an outline in <2.12
will now be drawn in their correct sizes, eg massive outlines. Projects
will need to be updated to reflect this.
- the default outline width set for the provided svg symbols (1 mm)
is much too large, so the symbols look bad with the default width.
This size needs to be modified in all the (~300 svg marker images)
- On the plus side, the long standing issue where most of the svg
symbols were rendered with white fill on white background and an
almost invisible black border is now fixed (refs #10908, #8538)
