exported, including data defined setting
This replaces the 2.x data-defined "number of pages" setting.
Instead of requiring users to develop an expression to return
the number of pages, instead we allow individual pages to have
a data defined control of whether that page should be included
in the export.
This is more flexible, and works correctly with the mixed page
size model for layouts.
when exporting to PDF
If an individual layout item needs rasterisation in order to
be exported correctly, it can now be individually rasterised
without forcing every other item to also be rasterised.
This allows exports to PDF keeping as much as possible as vectors,
e.g. a map with layer opacity won't force labels, scalebars, etc
to be rasterised too.
To accompany this, a new "Always export as vectors" checkbox
was added to layout properties. If checked, this will force
the export to keep items as vectors, even when it causes the
output to look different to layouts.
Fixes#7885
And start a generic test library for all item types to ensure
correct behavior for QgsLayoutItem subclasses
Currently justs tests to ensure that overriden
containsAdvancedEffects methods also call the base class
test
Allows for creating non-antialiased images from layouts. Note that
some layout item types do not correctly respect this setting, but
at least map items do and the API is in place for them to be
fixed later.
Fixes#9281
Run clang-tidy modernize-use-override to remove all the redundant
virtual keywords from overridden methods, and add some missing
overrides.
Another benefit is that this has also added the overrides
on destructors, which will cause a build failure if a base
class is missing a virtual destructor.
This forces Python code and plugins to become datum transform
aware, and given that upgrading python code is easy (just
add QgsProject.instance() as a new argument to the constructor)
it's relatively painless to force this on PyQGIS users.
Also fix upgrade the easy QgsCoordinateTransform c++ constructors
where the project is available, or where using QgsProject::instance()
is safe to do.
For others, just avoid the deprecated warnings until we can
get access to the correct project instance where the transform
is being constructed.
And automatically retrieve correct datum transforms for the
transform, based on the information in the context.
Also add a convenience constructor which takes a QgsProject
instance instead of a QgsCoordinateTransformContext and which
automatically retrieves the project's transform context and uses
that. This is designed to make it easy to upgrade existing
Python code (by adding just QgsProject.instance() to the transform
constructors).
