When a picture annotation item is set to the fixed size mode,
and has a callout anchor set, always place the annotation itself
at a fixed offset from the callout anchor. This mimics the
behavior of the old SVG annotation decoration.
Allows creating of callout lines (or bubble callouts) which
link the text to a map location. To create a callout, users
select the text item and then drag out the central x node
to the desired callout end point.
Callout styles can be modified through the layer styling panel.
This adds a new annotation item type for rendering paragraphs
of text inside a rectangle
Options are present for:
- Text format
- Horizontal and vertical alignment
- Margins
- Background and frame symbol
Can render SVG or raster images as items in an annotation layer.
Options are present for:
- Locking the picture's aspect ratio
- Drawing with a background symbol
- Drawing with a border symbol
- Linked or embedded pictures
edit operation on an annotation item
This is used for the item to return a representative geometry
of what the item would look like if the operation were to be
applied. It's used to generate a rubber band showing a preview
of the modification during interactive editing operations on
an annotation item.
For now all nodes just directly represent vertices in the item,
but the intention here is that they can represent any form of handle
which can be used to manipulate an item (e.g. a bezier curve point,
some "smart shape" handle for resizing or rotating an item, etc)
Because some annotation items have scale dependent bounding boxes,
we can only index items which have a fixed bounding box. Other
item bounds need to be dynamically determined based on a specific
render context. So rework the annotation layer index handling
to only index appropriate items and store other items in a non-indexed
item set.
This isn't ideal, because it means we need to clone ALL non-indexed
items upfront whenever we render an annotation layer (it's too expensive
to calculate their actual bounding box and selectively clone them,
as it's a process which blocks the main thread).
Hopefully we can think of an alternative approach to this down
the line so that we DO have some form of spatial index for scale
dependent items, unlocking better performance for annotation layers
with 10,000s of items. But we'll ignore that situation for now ;)
work correctly with curved geometry types, and tweak some API naming
accordingly
There's no need to be restrictive and only require linear geometries
for these items!
