Did I mention I hate boilerplate copied all over the place? ;)

The clear() previously offsetted the topleft rect corner for sprites
by _the sprite topleft_ position, which is rather unhelpful but for
sprites located at (0,0).

Another fix for a rendering glitch mentioned in fdo#45219 -
vclcanvas sadly does not properly implement compositing, so all-
black background yields dark shadows on semi-transparent objects.

Ultimately though, we should retire vclcanvas instead.

Use clearAll() here, to really clear the whole sprite area (clear()
does respect potential clip polygons)

vclcanvas has 1bpp alpha - so cut-off transparency at 98%
This looks for all practical cases close enough to full alpha.

Rather unexpectedly, calling setupOutDevState() with IGNORE_COLOR
does not return a proper transparency, but null. Fixed now.

So, the Impress transparence default is 50% - we'd want that to
*not* be fully transparent on vclcanvas, so shift the cut-off by one

This nowadays really is a pessimization.

Make sure transparent polygons really only cover the polygonal area,
not the whole bounding box for sprites.

Use GetIndex() instead of GetBlue() (does the same, but more
self-documenting); use opaque when no alpha channel consistently.

We're creating the bitmap to exactly match our output size -
so why rounding off total transformation again, incurring another
expensive bitmap scale down in the canvas?

With commit 0f0896c2, borders are drawn
immediately, but then the subsidiary lines are drawn over the borders,
hiding 1 twip wide borders completely.

...so that it does not erroneously always claim an update is needed, so that
SvtDocumentTemplateDialog::UpdateHdl_Impl does not always jump back to
OpenTemplateRoot() shortly after opening the dialog (and thus jumps away from
the last remembered folder).

Source range may not start from column 0.

That'd be super-expensive anyway.

As far as I can say, this value and all those negative values
are actually not valid in CGM anyway, but since I do not know
the code, I'm leaving them in, they shouldn't break anything.

This shaves off extra 5MB of memory with my test document.

No idea if this is proper fix or it needs to be done otherwise.

According to help Title should be the Title property of the document,
not the file name without extension. If that property is missing, we
fall back to file name without extension.

The algoithm for updating absolute refs needs to calculate the old
position based on the information before any updates to the RefData