Similar to previous plug-in but only for autotools. Separated in its own
commit for easy cherry-picking to `gimp-2-10` branch.
(cherry picked from commit a4a6ac59e0)
Exporting to psd could result in very large files which often failed to
load in both GIMP and PS when a group layer with a layer mask
was present.
Reported on our IRC channel with a sample xcf which made it
possible to figure out the problem.
(cherry picked from commit 8fdeaddbe7)
So far all dds images were loaded as 8 bit per channel which makes
sense for most but not all dds formats.
This commit implements loading in 16 bit for "L16" - a 16 bit
luminance channel.
In addition to that we improve security a bit by not assuming
that L16 is the only left over case but instead explicitly
checking the correct value of rmask for L16.
For other cases we now set an error with enough details
to identify the type of DDS image that needs extra
handling.
(cherry picked from commit fe228a6f6f)
# Conflicts:
# plug-ins/file-dds/ddsread.c
Let's increase the default size of the metadata viewer a bit.
Ideally we would add some logic to determine the width of
the first column since that one currently depends on the
length of the longest tag. However for now this change
will be enough for most cases.
(cherry picked from commit 165b50abcc)
The round corners script was assuming that the drawable always
was a layer, which is incorrect when a layer mask is selected.
We fix this by always requesting the active layer instead of
active drawable.
We also enable this script for RGB and GRAY with alpha
channel. Although it might not always make sense to
use this script when an alpha channel is present, there
can be use cases where it is perfectly fine.
So let the designer decide if this script is suited or not
instead of GIMP making that judgement.
(cherry picked from commit ed35579861)
# Conflicts:
# plug-ins/script-fu/scripts/round-corners.scm
Closes: GNOME/gimp#541
Reviewer note: thanks to Stanislav Grinkov for cleaning up and reworking
a bit the patch, such as renaming the procedure to dir-make, as per
Kevin Cozens' review.
(cherry picked from commit 11906fa82c)
Removing useless condition, add a g_return_if_fail() assertion for the
only (impossible unless bug) case which we don't expect. Also set
default mindist to G_MAXLONG instead of a magic number (which was ok now
but might become a problem if some day colormap allowed more than 16-bit
per channel colors).
Finally break when we reach a distance of 0 since we won't get lower
anyway, so better stop early.
Thanks to Rafał Mikrut and Øyvind Kolås for code commenting.
(cherry picked from commit d6dac25579)
We cannot just compare the drawable format with the model-type specs of
the color model. We need to include the space now.
In my case, some random screenshot converted to gray then indexed would
assert because the format is "Y' u8-space-gray-sRGB" (or for layers with
alpha: "Y'A u8-space-gray-sRGB"), hence indexed conversion failed and
ended up dark.
(cherry picked from commit c0e605ef96)
Looking at the documentation it is indeed red that should go
in the lowest bits and blue in the highest bits so just
reverse our code for red and blue.
We also update the version of our GIMP DDS plug-in,
this way we can catch and correct RGB10A2 images
written by older versions of our plug-in and correct
them.
(cherry picked from commit cad6273fed)
# Conflicts:
# plug-ins/file-dds/dds.h
With my previous commit, I improved the search action display and search
algorithm (which was returning wrong results), but we had lost showing
the non-sensitive reason in menu item tooltips. This fixes it, by
actually appending the reason, but only in the end, on the GtkWidget
tooltip (not in the action's tooltip itself).
(cherry picked from commit 13a02aea23)
Fixes:
> Calling error for procedure 'gimp-brush-get-pixels':
> Brush 'Circle (03)' not found
The data/brushes/Circle-3.vbr brush doesn't exist since commit
7aa12175a4 in 2012 as far as I can see.
(cherry picked from commit 65e10faf50)
… to GIMP not text layer rendering in image
Patch was merged n Cairo today, wouhou!
https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/114
If not mistaken, the fix should then appear in Cairo 1.17.6 or 1.18.0
(whatever comes next). As we are obviously not going to bump the Cairo
dependency so early, let's just add the patch, at the very least to be
used for our official builds. Also this way, we won't forget about this
issue in the future when we need to bump Cairo.
(cherry picked from commit 5f61d84570)
This is the same as what we did for #5357
but in the reverse situation. The reason
for not doing the same at that time was
because I wasn't sure if that was valid
in all cases.
Looking at the documentation it does seem
to be the right solution and is working for
the supplied example image.
(cherry picked from commit 48ff5313c3)
# Conflicts:
# plug-ins/file-dds/ddsread.c
… Cintiq 16).
Adding the patch provided by Knuckx. Note that the GTK3 variant of the
patch is already merged to gtk-3-24 branch and published since GTK
3.24.28. Nevertheless since the contributor also provided a GTK2
variant, it would be a bit of a waste to let it go down the drain,
wouldn't it?
So let's try and use it in our GIMP 2.10.x packages for Windows.
This is a patch for issue #913, the infamous "non-existent floppy drive"
or other unreachable network or unmounted drives. Well at least it
*should* fix the issue, but GLib developers are hoping we could test. So
let's add this in there for our next Windows package.
(cherry picked from commit 7e2a0238a2)
Removing this check makes the treatment of LittleCMS consistent with
all the other dependencies checked in the same file, which only check
that the runtime version is at least the required version.
As long as we were compiled against LittleCMS >= 2.8, and are now
running against a version that has at least the same symbols, it doesn't
necessarily matter whether the version we are running against is the
same one we were compiled against.
Distributions like Debian and Ubuntu track the versions in which
individual symbols were introduced, which allows runtime dependencies
to be weakened when no newer symbols are actually used; this is
practically necessary when working with very large numbers of packages,
to avoid a new version of a dependency library unnecessarily blocking
upgrade of dependent packages. However, this doesn't work if dependent
packages add their own checks that bypass this mechanism.
Signed-off-by: Simon McVittie <smcv@debian.org>
(cherry picked from commit dda65d85c3)
Also ".sun" is a possible (and common) file name extension for Sun
Raster images, according to various sources and samples I found (these
samples with .sun extension also opened fine in GIMP, so it's not just a
subvariant which we may not handle or something of the sort). This one
is not so important though as we also register magic bytes for detection
(which is the proper way), but it can still be useful, mostly for
exporting (as we will direct to the SunRaster plug-in if someone tried
to export a file with .sun extension, since no other file format uses
this extension AFAICS).
There is no functional change, I just had a look at this plug-in while
handling !428 and realized this format was not present in the MimeType
list (which is used to generate the desktop file, in order to have
proper mime types, not detection based on extension only, unlike
Windows in !428).
(cherry picked from commit cd3333c6d3)
Nowadays .rs is the extension for the Rust programming language files,
and it's confusing that GIMP is trying to associate with them.
A simple rename of existing .rs images to .ras will allow them to be
opened again.
Note by reviewer: ideally file association should not rely on filename
extension, and should be detected properly (i.e. file "magic"). This way
even extension clash would not be a problem (format would be detected
whatever the extension used). Unfortunately it's apparently not the case
on Windows.
Anyway since nowadays chances to see a Rust code file are likely much
higher than seeing a Sun Raster image file, let's just accept this patch
and drop association of `.rs` on Windows.
(cherry picked from commit 809e045ead)
Fix again these warnings:
> cast from pointer to integer of different size
(cherry picked from commit 2c6e21b1e7)
Note: the absence of this made script-fu crash on Windows 64-bit. See
issue #6664. Why this suddenly appeared and never happened before GIMP
2.10.24 is a big mystery.
… there are no such data available.
No need to have people test and wonder what it changes when it makes no
difference. Also adding a tooltip to make the "present on import"
condition a bit more obvious (hopefully).
This is only on `gimp-2-10` for now, for the 2.10.24 release. I will
port this to `master` branch later.
Contents of these arrays are assumed to be limited to a specific range.
While it did work sometimes (because a further processing would randomly
regenerate some of the indexes and correctly limit the range), it often
crashed.
This commit fixes the crash, but I am not sure this plug-in is working
exactly as expected regarding data load/save. It feels like you would
expect to always get the same patterns with a same source data. Yet
there is further randomization going on.
Oppositely when saving data, and re-loading it later, I would expect
once again to get back the exact same patterns I had when saving the
data. So it would be a way to save the result of randomization (as
chances to get back a pattern one liked are slim by definition when it's
created randomly).
Right now, it doesn't behave at all like this. Files are only used as
some kind of random seed, not as a way to save/load patterns. I feel
this was not the purpose of the file handling here.
(cherry picked from commit 7fb696206e)
