While at first, the idea of always loading PDF with transparency seemed good
(commit 7aff7e9c70), I realized that a lot of administrative PDF (generated with
text and vector graphics, rather than scans or alike containing raster) actually
have transparency. So now all these documents load with transparent background.
Clearly all the office software are assuming that PDF readers will fill the
background with white.
So add a checkbox to decide whether or not to fill the image with white. I don't
update the PDB procedure. I'll just do this on the main dev branch (while also
updating a bit the code to newer API).
Fortunately I regularly open such PDF documents with GIMP and could witness this
no-transparency expectation before we released GIMP 2.10.34! 😅
The magics used for detection for CUR and ICO are not very unique and
interfere with the detection of certain types of TGA images.
Since these TGA images are regularly used, it seems better to only base
CUR and ICO detection on the extension, just as we do with TGA version 1
files.
See also issue #7912
Krita had a bug where it incorrectly saved 4 for the alpha bits instead of
8. We will allow 4 and convert that to 8 to be able to read the incorrect
TGA images.
The likelyhood of real TGA images with 4 alphabits seems pretty low, so it
should not interfere with real images that have this set. We were not
supporting that anyway.
(cherry picked from commit 5f9415a641)
Added the 2 new PDB functions. I should not have added these so close to release
(because these add 2 translatable strings for undo), but anyway the added
strings are barely GUI-facing as these functions are for plug-in developers.
And I really wanted to finally review these MRs which have been sitting there
for months. Sorry translators!
- fix a typo s/Commponent/Component/.
- Add &std_pdb_compat() to the new PDB procedures (I realize that's probably
what the contributor was asking about, back in !446). Not sure if it's right
as there were none in this file, but these are clearly just wrappers around
GEGL ops, so it seems fitting.
- Some alignment fixes.
- More accurate "$since" variables.
Original issue: #8581
1. When an image with a non-xcf format is loaded, within GIMP core it
qualifies as an imported file. (See gimp_image_get_imported_file
function)
2. But the guillotine plugin cannot propagate this information.
It can only set the file path on the new image it creates, and it uses the file extension of the original imported file.
3. But since the filename is set by the plugin is the actual filename not imported filename,
the gimpsavedialog.c module cannot differentiate it. This results in the
incorrect file extension being set in the "gimp_save_dialog_set_image"
function.
This issue can actually be present in other plugins as well that
generate new images which has to be checked.
This commit is a fixup commit for MR !790 which had a few issues:
- The args for shadows and highlights adjustments are "shadows-ccorrect" and
"highlights-ccorrect" respectively.
- Also fixing generated code.
This implements the full fix to the problem noted in the prior commit.
While it no longer crasheed when applying a function after clearing the
console, Jehan reported it still showed a CRITICAL message. This should
fix it the same as the 2.99 branch.
GTK2 get_iter_at_line_offset() does not allow invalid offsets unlike
GTK3 version. Clearing the console creates an invalid iter due to an
empty buffer.
This patch attempts to resolve it by adding a ">>> " output when the
console is cleared, thus preventing the invalid iter issue.
This reverts commit 13284c8953.
Actually I should not have backported this change from the `master` branch.
These functions are still public in 2.10 (and internal in the main branch).
This should fix our CI.
A bug in babl would run the color conversion twice when the input and output
buffer is the same and a LUT is available for the color transform. This is a
workaround in GIMP code (especially because we still don't require the latest
babl version), though a real bug fix will soon happen too in babl itself as
well.
The defcheck.py file finds these errors:
> Problem found in /home/jehan/dev/src/gimp/libgimpwidgets/gimpwidgets.def
> the following symbols are listed in the .def-file,
> but are not exported by the library.
> - gimp_color_picker_cursors_get_resource
> - gimp_icon_pixbufs_get_resource
Indeed these don't exist. Unsure why the autootols check failed to
report these until today.
(cherry picked from commit 01e87819ce)
Some PDF have transparency on purpose. Filling with white, without any question,
is counter-productive and prevents from working on such PDF files.
Note that we could add an option with a checkbox, leaving one to decide whether
to fill the background or not. But it feels over-engineering the issue. The PDF
is transparent, so that's what we load, and that's it. If one wants to add a
background, it's easy to add a layer at the bottom of the stack (and they can
make it any color they want, not just white), after loading the file.
(cherry picked from commit c369827725)
I had a TIFF file which would crash while triggering an error, inside g_logv()
code (and according to the stacktrace, even probably inside some lower level
printf implementation code).
The reason was that I already processed the variable list with
g_strdup_vprintf() and printf didn't like this va_list being reused, then
segfaulted with some "Cannot access memory at address" error.
The alternate fix was to first copy the va_list in the first use with
va_copy()/G_VA_COPY, yet since we already processed the format data, I thought
it was useless to do this. Let's just directly use the formatted string.
(cherry picked from commit fb1f16d4b8)
...when it shouldn't.
Backport of Wormnest's code.
When overwriting the same file when exporting, we didn't check if the
image previously had a thumbnail. If the default setting in Preferences
is to add a thumbnail, then it would add one where it shouldn't.
Since thumbnails get saves as part of the EXIF metadata, we need to check
that to see if there was a thumbnail in the original image.
However, we were always removing the thumbnail from the metadata on import.
Let's delay removing this metadata until we need to, which has the
advantage that the metadata in our viewer is more complete.
When exporting starts, we add a check in gimp_image_metadata_save_prepare
to see if there was a thumbnail in the EXIF metadata. If not, then we
disable the thumbnail flag.
In gimp_image_metadata_save_finish we remove the thumbnail metadata when
the user doesn't want to save a thumbnail, or when the image format
does not support EXIF.
Apparently GDK/Win32 sends the "grab-broken-event" signal before the "clicked"
signal. This has only been changed since GTK4 so far.
Anyway the bottom line is that GimpContainerPopup would process a handled on
"clicked", using the object destroyed when "grab-broken-event" happened as
callback data. The solution is to make sure that the object stays alive long
enough. So I'm changing gimp_editor_add_button() to connect to signals with
g_signal_connect_object() (since all usage of this function was used with
GObject callback data, it was not a problem).
See discussion in !815.
As a side change, gimp_container_popup_dialog_clicked() should emit the
"cancel", not "confirm". This part was taken from MR !815 by Lloyd Konneker.
(cherry picked from commit f77f772f56)
is positive or zero. Sometimes the calculated `y` or `bg_y`
values are negative because the histogram value was divided
by zero (when max == 0.0).
Resolves: #9132 (Gnome/GIMP bug tracker)
(cherry picked from commit 9b517fbf7d)
The Y offset of the statusbar tool icon is too large, which pushes it
off-screen. This scales the offset by the size of the icon to
prevent this problem.
This reverts commit f7e7f396aa.
See issue #8269.
For GIMP 2.10, I'll just revert this commit so that we get back to pre-2.10.32
situation. For 3.0, we'll try to do something better.
