If a filter is inactive/invisible, it does not
affect the appearance of the drawable.
Therefore, when merging all active filters,
those filters should not be removed.
This patch adds conditional checks for
gimp_filter_get_active () and does not
remove filters on merge if it returns
FALSE. It also adds sensitivity checks in
the GUI so that the merge down button is
not active if there are no visible filters.
when loading a specially crafted PSD.
After fixing the issue in the previous commit, using the poc from that
issue, a new issue surfaced where the ptr_array used for
img_a->alpha_name did not contain any names. Trying to access the
first index then caused a crash, because apparently that is only
valid if at least one item has been added.
Let's fix this by only creating the ptr_array when we know for sure
that we are going to add an item.
in fread_pascal_string
In plug-ins/file-psd/psd-util.c, the function fread_pascal_string()
allocates a buffer with g_malloc(len) and reads len bytes from the file
into it. The buffer is not null-terminated, but is assumed to be in
later code.
This causes it to read past the end of its allocated region with a
specially crafted PSD, causing a heap-buffer-overflow.
Fix this by alloocating one more byte than its length and set that
to '\0'.
When opening a saved gfig file that came with GIMP, I noticed
several criticals:
GEGL-CRITICAL **: 09:16:16.320: gegl_color_get_format: assertion
'GEGL_IS_COLOR (color)' failed
After that the gfig plug-in crashed.
After examination I noticed that the initial style gets copied. In
the case of the default style this means the source and destination
are the same.
When duplicating our code first removed the GEGL color objects from
the destination style before assigning from the source. But because
they are the same, this leads to invalid colors. Before the change
to GEGL colors they were simple values where reassigning didn't matter,
but here it does.
Since the same function does other assignments with resources that
may cause later issues, let's just return right away if the source
and destination style are the same.
Resolves#15814
As noted by JungWoo Park, since in fread_unicode_string ()
we read in a 32 byte value and then attempt to allocate
double the memory, we run the risk of overflowing and crashing
at g_malloc ().
This patch converts that function to g_try_malloc () and checks
if it returns NULL before going further.
Per user request, this allows you to flip
on-canvas items with the arrow keys when
the Flip tool is active. Left/right arrow keys flip
horizontally, up/down arrow keys flip vertically.
Note that having an active guide highlighted overrides
this distinction - pressing any arrow key will always flip
over the guide, same as with the mouse.
In particular, for indexed images, color choice will happen within the
colormap.
The following uses are made context-aware:
* Test tool options color;
* Fill colors.
These other uses will not be context-aware:
* Padding, quick-mask and padding colors;
* Out-of-gamut colors;
* Generically generated color buttons (e.g. in filter dialogs);
* Foreground selection's mask color;
* Grid colors.
Looking in these tests, most are hard to test with just the API. These
will need to be properly replaced once we'll make use of a UI testing
framework allowing such tests.
Issue #15763 is again mostly false positive crashes of the unit tests
because the code is only partly GIMP code, arranged differently as what
a full GIMP process would actually do.
The new tests just runs on the real GIMP code. Now the difference is
that we don't test the UI by doing this, but this can be debated whether
the previous tests were actually running on the UI themselves (they were
mostly running some core code directly and sometimes activating some
actions or raising dialogs (gimp_test_utils_create_image_from_dialog()),
but again not by actually clicking or hitting keys as a human would do.
It's not proper UI testing (cf. #9339 of #13376 for further discussions
on this topic).
So in the meantime, let's go with this intermediate step. At least now,
such tests would run actual GIMP code and would catch issues which could
really happen in a GIMP process.
setlocale(LC_ALL, "") queries the user locale.
setlocale(LC_ALL, NULL) also queries the locale, but not the user
locale. It actually queries the programs locale, which by default is C.
Otherwise the user would need to have en_US.UTF-8 available no matter
what.
Check that derivates UTF8 of C locale aren't used as well.
Bug: https://bugs.gentoo.org/969468
Fixes: 88261f8b4c
Signed-off-by: Alfred Wingate <parona@protonmail.com>
file with INT16_MIN layer count
In PSD files the layer count is a 16-bit int that can be negative.
A negative value is a flag for transparency.
In our code, after setting the flag, we negate the value. However for
-32768 the minimum possible value, there is not 16-bit positive value,
so the value stays negative. This can cause a heap allocation failure
when we use this value to allocate memory.
To fix this, we check if the value is G_MININT16 and error out in that
case.
This function is counter-productive, since we now want to have both
deprecated and deprecated_since together. But there is no generic
"since version" to be used for such a macro.
So let's just have people explicitly add both variables (and error out
the generation script if they miss any).
… std_pdb_deprecated for previously deprecated functions.
The &std_pdb_deprecated() call won't set a "Deprecated since"
information since this can't be made generic anyway. We have the info,
it'd be a shame not to document it!
Also it clears the blurb and help string, which I find unhelpful (even
for deprecated functions, it's better to have proper documentation!).
I just realized that the way we have been using "Deprecated:" tag was
wrong. It has a version first, then further descriptive text.
Fixes display "Deprecated since: Unknown" in gi-docgen documentation.
I have manually tested each and every of the deprecated functions,
making sure we don't lose any feature. As expected, we don't. Having
dedicated libgimp functions may feel a tiny bit easier to call but this
is not scalable. We can't do this forever, with one function per filter.
And fortunately we won't have to, since now we can call filters on any
drawable directly! It also comes with the following generic advantages:
* It works with any filter, even third-party ones;
* We can also append filters non-destructively for later removal or
edits (the deprecated functions were always merging the filters);
* If the filter evolves, e.g. with new arguments, it should not affect
the API (though we should implement GEGL operation versions);
* If we don't need to set all arguments (e.g. leaving many args with
default value), the filter API may even be simpler and shorter;
* The filter API will be much less "opaque" thanks to argument naming
(rather than a long list of integers, doubles, etc.).
Specifically to the now deprecated functions, I noted the following
weaknesses on the deprecated API when testing:
* gimp_drawable_colorize_hsl() was missing a "color" argument;
* gimp_drawable_extract_component() had the enum argument "component"
set as an integer, which is particularly opaque when re-reading
existing code. Whereas the filter API uses generate choice strings
which are self-explanatory! For instance choice RGB Red is 0 with the
deprecated function but "rgb-r" with the filter API.
* gimp_drawable_levels() was missing "trc" argument (as noted in
#15681).
And as expected, no features are lost.
Note that I didn't deprecate the curves functions yet, because we need
to implement the GimpCurve type in libgimp first.
There are a few more functions which I didn't deprecate yet, because
they don't use a filter directly, but some core functions, though for
some of them, it is very likely they can be efficiently reimplemented
with the filter API too. I'll have to look closer at it. It looks like
we may have to implement GimpHistogram in libgimp too though.
… or a content to use as-is.
Until now, it was assuming the deprecated content was a function. So if
I want to deprecate in favor of a GEGL op (e.g. "gimp:levels"), we'd
have warnings showing a "Deprecated: Use gimp:levels() instead".
Now it will try to recognize the type of suggested replacement with a
basic heuristic: if there is a space, it'll just use the replacement
text as-is; else if there is a colon, it'll assume it's a filter name.
Else it assumes it's a replacement function, as it used to.
With an older configuration of a last run from before the new args had
been implemented, Curve Bend plug-in was crashing at start. The various
"*-point-*" argument were serialized as: (upper-point-x 0)
That meant an array of size 0 and that was enough to have the variable
load_settings_data set to 0 and therefore settings-data (which had the
real data) was never deserialized.
When system settings use , instead of . for decimal separation,
5753ac75 broke for legacy XCF grid parasites because numbers
were not encoded consistently. This patch brings back the
sanitation step with g_ascii_dtostr () that ensures all numbers
are saved with . decimal separation.
