In file-xpm, use_x_api is only used when
GDK_WINDOWING_X11 is defined. However, it was
included as a general variable so it threw an unused variable
warning when compiled on other systems.
This patch moves the variable declaration inside the first
#ifdef GDK_WINDOWING_X11 block of the parse_colors ()
function.
We introduced a bug in GIMP 3.2.2 where some text layers with NULL
markup (i.e. defined as bare text) would store an empty markup inside
the XCF. As a consequence, this empty markup string would override the
text.
This bug got fixed with my previous commit. Unfortunately the XCF files
would still be available in the wild and they would still lose their
content upon editing the text layer, if we were to only fix the XCF
saving. This additional commit will add some special-casing to handle
this edge case, which would simply delete the empty markup upon
encountering it. This makes our XCF loading robust to faulty XCF files.
Reverting a part of commit fa097df9 which should not have been merged,
and in fact which was not useful anymore for fixing the original issue.
This fixes part of #16169, which is that because of this change, we were
creating broken XCF containing both a text and a markup variant for
text-only text layers. Typically it was storing:
> (text "I love GIMP")
> (markup "")
Now we don't create such broken XCF anymore, but I'll want to strengthen
reading code too, so that we can salvage such XCF files, already
existing in the wild.
We dropped 32bit Windows support in
GIMP 3.2.2, which also removed the
32bit-only TWAIN scanner plug-in.
This patch adds a new plug-in that uses
the 64bit compatible WIA API for scanning.
It should restore the support for scanning on
Windows.
...against IHDR bounds in APNG loader
The pixel buffer is allocated using base image dimensions from the IHDR
chunk, but row write offsets were computed using the per-frame dimensions
from the fcTL chunk with no bounds check. A crafted APNG file with
fcTL.width > IHDR.width or fcTL.height > IHDR.height would cause
out-of-bounds writes into the heap on every row after row 0.
Reject fcTL frames whose dimensions or offsets extend beyond the base
image dimensions before proceeding with decoding.
Even the fact we have a libgimp gimp_quit() function which was not
calling the PDB proc of the same name (and indeed doing something
differently) was weird and confusing.
Anyway we should not allow random plug-ins to basically kill GIMP
without any way to do anything about it, and probably lose all your
unsaved work. This is just wrong IMO.
We'll see if anyone wants to disagree, since anyway this won't be
removed until GIMP 4.
Now instead of just unexpectedly ending the plug-in process, let's
gracefully return with a GIMP_PDB_EXECUTION_ERROR and proper error
message, when any of the stream-writing function fails.
I am going to deprecate this function. We should stop just killing
plug-ins randomly when things are bugged. Instead we should still try
and return cleanly (with an error status and message).
It is really useful on pipelines used only for testing:
- GIMP_CI_MESON_CLANG
- GIMP_CI_MESON_MSVC
- GIMP_CI_MESON_APPLECLANG
- GIMP_CI_RASTER_ICONS
- GIMP_CI_CPPCHECK
This fixes issue-bot wrongly in the middle of nightly packages,
which was not my intention, since these pipelines are flaky
and all are run with CI_COMMIT_TAG before the releases (with
exception of the flatpak, which is checked by the packager when
syncing the manifest, so issue-bot is also useless there)
This is a fixup for commit a85e5286fd.
While neither gimp_env_init() and gimp_env_exit() are supposed to be
part of the public API (therefore these docs won't be part of the
gi-docgen docs either), it's better to properly document this with
explicit text.
This mostly reverts commit 987dc52160
(with some conflicts fixed as the file got further touched).
This table was already properly aligned as what matters is the generated
INSTALL file, which is what will end up in our source tarballs. This
file is also published on the developer website. The reverted commit was
completely breaking the formatting. 😅
Let's create the folder returned by gimp_temp_directory() ourselves, the
first time this function is called, using a randomized name. This will
ensure that we won't conflict with another user running GIMP on the same
machine if using the base /tmp/ (which is usually the case on Linux).
Furthermore, since we create the temp folder at this level, we will also
delete it when quitting (but only if it's empty, as it should). Also I
use a single-level folder above the generic temporary directory, this
way, it's easier to track and we don't have to delete 2 levels of
directories anymore.
When the environment variable GIMP3_TEMPDIR is set though, we do not
create the folder, nor do we try and delete it.
And use the function in script-fu. While we want wrong resource names to
trigger WARNINGs in Script-Fu scripts and plug-ins (because these can be
considered as a bug), we don't want it to happen when the resource is
not loaded on purpose (mostly it means that we run GIMP with --no-data
or --no-fonts). This was happening in our own builds when running GIMP
through the in-build-gimp.py script and that was always very annoying.
Now in such a case, we will only output an INFO message on stderr (it's
still a good idea to warn about this, because if we imagined someone was
running a script non-interactively, which called one of these
procedures, they may have relied on the default value of some arguments.
Therefore they'd want to know about such a behavior change).
The INFO message "a stray image seems to have been left around by a
plug-in" was annoying when GIMP is run non-interactively, and when it
was about images open from command lines. Typically this message would
be visible on our CI when the various gimp-data scripts would fail. This
could only confuse script developers.
The fact is that while a plug-in (or batch script) should definitely
clean after itself by deleting images it created (unless it gave it a
display, in which case ownership is moved to the GUI), it is absolutely
expected that images opened through the command line would still exist
at exit.
It is not a fix yet for #14681 but would provide nicer and earlier error
when a call to gimp_temp_file() fails, which may happen in some cases.
E.g. if the temp directory doesn't exist and we fail to create it.
As a test, if I delete /tmp/gimp/3.2/ and give root ownership to
/tmp/gimp/, now the error when opening our gimp-splash.xcf.xz is:
GIMP-Error: Opening '/path/to/gimp/gimp-data/images/gimp-splash.xcf.xz' failed: Error creating directory /tmp/gimp/3.2: Permission denied
This is a further improvement, for the specific case which appeared on
issue #16160. Basically here for the specific case when we have
permission issues, or other similar issues where we fail to either load
the input image, or export to the temporary file, we would get more
explicit error messages. And this would also show in the stderr output
of the in-build-gimp.py script.
In particular, when reproducing #16160 permission issue, the build logs
now contain this error:
GIMP-Error: Opening '/path/to/gimp/gimp-data/images/gimp-splash.xcf.xz' failed: Error creating temporary file '/tmp/gimp/3.2/gimp-temp-1719540.xcf': Permission denied
This should better help diagnose similar issues in the future.
… even when we have no display.
gimp_message() supports a NULL handler object and we get proper
GIMP-Error message printed on stderr, e.g. when GIMP is run from the
build system.
We want as much info as possible when debugging our build scripts.
This is part of fixes to improve situations such as seen in #16160.
Resolves#14583
If the user chooses to vectorize PDF layers with single colors,
get_layer_color () is run to use histograms to determine if they
are indeed a single color. gimp_drawable_histogram () is used to
get the RGB values as averages. This function returns values in the
0...255 range for 8-bit images and 0.0...1.0 range for all the
other precisions.
However, we did not properly normalize the values, resulting in
blown-out white layers when exporting 8-bit images. This patch
checks if the image is 8-bit and divides all values by 255.0f in
that case.
It also checks if the image is in linear precision or not, as
gegl_color_set_rgba () assumes the color values are linear. If not,
gegl_color_set_pixel () is used instead. Finally, the color mode
checks are made a bit more robust in preparation for future color
modes like CMYK.
