In fact, the previous commit was unneeded and we could have done without
reverting the old commit. On the other hand, a buffer using another
buffer as "source" may be nicer in memory.
But the previous commit alone was not right as group boundaries were
wrong. In fact, right now, we can see that group boundaries are computed
using only the children layers (except for pass-through of course), not
including any effects they might have. And the buffer passed to
gimp_drawable_set_buffer_full() was the projection's buffer itself — it
was shared, which was also why copying at setting time was wrong —, in
the case of a group layer. That means that when we translated to (0, 0)
offset, either we would have moved the render to the wrong place, or
moved the boundaries to the wrong place.
The offset needs to stay what it is, even when it's not (0, 0), for
group layers.
Another alternative fix would be instead to fix layer groups' boundaries
to encompass the full projection's render. But I just went with this
special-casing of group layers instead.
Part of it reverts commit 3a53e4743e.
Another part is a fix to the CRITICAL mentioned in this commit.
This being said, it's clearly not entirely right yet. The boundaries of
the layer when the filter is merged are not correct, which is especially
visible when trying to draw on this layer afterwards.
Also the layer group boundaries (when reproducing the steps in #16010)
are clearly wrong too.
A crash could happen when a duplicate nick was found due to incorrectly
freeing the content of 'choice->keys' which holds the nicks and not
GimpChoiceDesc. Instead, the nick needs to be simply freed.
As said on cbe2f6be, Inno does not support modifying installations at
all, not even canceling/undoing modifications like reinstall and update.
This limitation become more apparent after the fix 24e42dd1 so
let's prevent the users being damaged by such major Inno pitfall.
968cf06a only loaded the rectangle area that the
selection was contained in, rather than the actual
channel data. This patch extended the code to
also read in the PSP_CHANNEL_BLOCK data, add
it to the selection GeglBuffer, and then shift it over
into the correct location.
The Path Import dialog has an option to choose whether
the imported paths scale to match the dimensions of the
image or not. While this variable guards scaling the paths
themselves, it did not prevent the viewbox from being scaled
Thus, the paths always appeared to be scaled.
This patch adds a check for the scale parameter in parse_svg_viewbox ()
and conditionally scales the viewbox based on user input.
It have been so annoying to check the commit diff on GitLab and
noticing that it is widely different from the one on the IDE.
After all, there is a reason for the Coding Style prohibiting tabs...
This was tested with both in-house MacPorts, in-house HomeBrew and
legacy CircleCI builds and I confirmed it works (it is needed only
by the in-house MacPorts builds).
Resolves#16076
As reported by chamal, it is possible to craft a
Jeff's Image Format image with header values that
are larger than the file size. This can lead to buffer
overflows when loading the data. This patch adds
bounding checks based on the size of the stream.
