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.
Resolves#16075
As noted by chamal, it is possible to cause a buffer overflow
in a crafted SFW file. This patch adds bounds checks to prevent
this from occurring.
See: 21895406db
Due to gexiv2 rebuilding it now links to exiv2 0.28.8 released recently.
As a result, gimp-console started to fail with Windows error 3221226505 at
splash image generation, because exiv2 from msys2 don't have our workaround.
Let's fix by bumping our custom build so gexiv2 can find it properly.
Resolves#16058
Per mzfr's observations, this patch adds more
safeguards to PVR import. Memory for data and pixels
is allocated and checked rather than using arrays.
Twiddled patterns are increased to 2048 and we
verify the dimensions are in that range before trying
to access. If users share an image that is larger than
that, we can increase this limit further.
Resolves#16056
Per mzfr, we should check if the cursor exceeds the
icon total size in icns_slurp () (per OSX icons) as we
do already in icns_decompress ().
Additionally, we were not deleting the temp_image created
to load each icon, and in fact we were making an unnecessary
blank temp_image before receiving the one from the PNG &
JPEG2000 procedures. This patch fixes both problems.
Per mzfr, we should dynamically allocate memory
for the PAA plug-in pixel data rather than rely on the image
being small enough for an array to store its information.