This commit also makes snap to grid and snap to vectors work off-canvas.
Since we now have off-canvas viewing, it just makes sense that snapping
would work there too.
Note that I disable snap to grid when "Show All" is OFF. I am actually
unsure this is right (as "Show All" is a view action, and we usually
don't change behavior based on view actions; for instance snap to guides
are not disabled if guides are hidden). Yet I noticed we do this in
various other features when off-canvas. We kind of use this view flag as
a switch for features working off-canvas (for instance, color picking
works off-canvas only when "Show All" is ON). So let's keep the same
logics for now at least.
Snap to guide or snap to vectors will always work though, because guides
and vectors are always visible off-canvas (even when "Show All" is OFF).
They always have been (visible, not snappable off-canvas; now they are
both).
(cherry picked from commit 82438728fb)
If the interp file contains CRLF, the \r is read as part of the
executable file name, and gimp searches for python3.exe\r.
(cherry picked from commit b134da1f39)
This commit fixes the issue when requested page width/height was
not honored because DPI resolution value was constrained to whole
integer numbers only.
XMP metadata saved by GIMP 2.8.x or earlier can have duplicate tags
making the XMP data invalid. There's not much we can do without a
whole lot of processing and complicated code and even then no
guarantee we would catch everything.
Instead let's just try to improve the message to the user so they
will be more likely to understand what's going on.
(cherry picked from commit 6df6332f9b)
Although I haven't been able to reproduce it, it is apparently
possible to get a Stack Overflow when loading xcf files with
presumably very large dimensions on Windows. From what
I'm reading Windows normally has a smaller stack size than
Linux, probably why it hasn't surfaced there.
Instead of allocating on the stack let's do a g_malloc0
combined with g_free.
(cherry picked from commit 6b65998bf7)
Argh I should have properly reviewed !392 (commit c264f0b705).
It was leaking the return value of a g_path_get_basename().
(cherry picked from commit 1873f0d65c)
darktable GUI is "mangled" when opened from GIMP for a reporter. There
was already some debug info outputted (when running with DARKTABLE_DEBUG
environment variable). Adding the environment list (and some separation
titles to make it easier to distinguish what is what). Hopefully it will
help debugging.
See #6195 and https://github.com/darktable-org/darktable/issues/7402
(cherry picked from commit 7465b0782a)
We were not handling all possible record sizes for mask info and
in case it was an unknown size we set everything to 0 instead
of reading the parts we do recognize.
Let's make it more flexible by reading the parts we do know
about and skip the remaining data if any.
Also added a few more g_debug statements to make it
easier to check some values when needed.
(cherry picked from commit 83ab86eb8b)
When testing for the presence of extra channels we were not taking into
account all values of TIFFTAG_PHOTOMETRIC causing incorrect messages
that we had a non conformant TIFF without ExtraSamples field.
Since the same test is used twice I separated the code into a new function
and also added another related function to have similar code grouped
together for easier maintenance.
(cherry picked from commit f489976b05)
GIMP was exporting certain BMP images with 1, 4, 8 and 24 bpp
with an incorrectly set value of BI_BITFIELDS for compression,
see issue #6144.
According to the specification this is not supported but testing
shows that many image viewers and editors load these
images correctly.
Since allowing these unsupported values for bpp does not
seem to have any negative side effects and is easy to
implement let's add this.
(cherry picked from commit e55e078245)
The Microsoft specification for BITMAPV5HEADER says that
BI_BITFIELDS is valid for 16 and 32-bits per pixel, but we
were also using this flag for other values of bpp when
no rle compression was used.
Since this specification doesn't mention 24 bpp or other
values use BI_RGB instead.
(cherry picked from commit d8c164ced3)
Information in issue #6200 revealed that 0 as default value for
the blue channel is a lot more common than 255 so let's use
that instead. The discussion and testing revealed no negative
effects for the other formats that use the same code to
initialize the memory to read blocks of image data.
(cherry picked from commit 691548579a)
Since older versions of our GIMP dds file exporter incorrectly
saved BC5 dds images with the red and green channels
swapped we should fix that. Since the exporter already
wrote the plug-ins version number and that it is written by
GIMP we can check for these incorrect images.
To enable that we increase the plug-ins revision in this
commit and swap red and green channels for images
that have an older version number and are of the
correct type.
(cherry picked from commit a4cc8b7070)
# Conflicts:
# plug-ins/file-dds/dds.h