This adds a blend mode for all known psp blend modes that were not
converted yet except for adjust.
I couldn't find any information about adjust and it's value of
255 suggests that it is not a normal blend mode.
AVIF import and export (need libheif >= 1.8.0)
High bit (10/12) import and export
Auto pre-select suggested output bit depth in save_dialog
NCLX color profile import (link with lcms)
Metadata import (link with gexiv2)
Plugin will not return GIMP_PDB_SUCCESS in case of failure to import file.
Starting from psp file version 4 the specification recommends to always use the
block/chunk length to determine the next part of the image. This way it is
possible to skip parts you don't know or don't care about or additions in
newer versions.
This change makes sure to always do this which fixes reading several images
which crashed the plug-in before.
Also only try to read layer data if it is a raster layer.
According to the PSP specifications "Each scanline in the image data is stored on a 4 byte boundary. "
Based on all actual images I've seen this is incorrect. Possibly it is a leftover from an older specification.
Color picking on a single layer still works as it used to. On multiple
layer, it will now pick on the composited color, similarly to sample
merged if only selected layers were made visible.
The PDB/libgimp function gimp_image_pick_color() is also updated to work
on multiple drawables too, giving the same ability to plug-ins (the only
call to this function in core plug-ins have been updated).
When several layers are selected, select their render, similar to how
"edit-copy-visible" would have copied an image with only these layers
made visible.
Also apply the same logics to PDB function gimp_edit_copy() which can
now be used on several drawables at once.
This commit just changes our saving API (i.e. the GimpSaveProcedure
class) to take an array of drawables as argument instead of a single
drawable.
It actually doesn't matter much for exporting as the whole API seems
more or less bogus there and all formats plug-ins mostly care only
whether they will merge/flatten all visible layers (the selected ones
don't really matter) or if the format supports layers of some sort. It
may be worth later strengthening a bit this whole logics, and maybe
allow partial exports for instance.
As for saving, it was not even looking at the passed GimpDrawable either
and was simply re-querying the active layer anyway.
Note that I don't implement the multi-selection saving in XCF yet in
this commit. I only updated the API. The reason is that the current
commit won't be backportable to gimp-2-10 because it is an API break. On
the other hand, the code to save multi-selection can still be backported
even though the save() API will only pass a single drawable (as I said
anyway, this argument was mostly bogus until now, hence it doesn't
matter much for 2.10 logics).
Fixes the following bug:
> warning: absolute value function ‘abs’ given an argument of type
> ‘glong’ {aka ‘long int’} but has parameter of type ‘int’ which may
> cause truncation of value [-Wabsolute-value]
Let's go with the logics "bottom layer is first", which is also the
logics in animated formats. Hence changing the layer order on loading
multi-page PDF.
… defaults to FALSE for PNG, TIFF.
The logics is that in most case, when alpha is 0, you don't expect color
to be retrieved and some people were bothered by this when erasing data
with eraser tool or selection deletion.
For the WIP image as well as for XCF format, we definitely want to keep
color data as there are workflows where you would want to erase/unerase
pixels subtly (selection also are not binary and should not be expected
to erase color data on layers with alpha channel). So we want to keep
the non-destructive behavior there.
Yet for export formats, going for "deleting what looks deleted" is a
valid approach, especially as it has been argued that experienced users
would know how to read and change the format options (and these
experienced users are likely the ones who may have valid reasons to want
pixels with full transparency to keep color values).
PNG and TIFF were the only 2 formats where I see such options, so
changing the default for these 2 plug-ins.
* Don't generate our own marshallers if they are available in GLib
already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
default marshaller provided by GLib. See commit message of commit
39e4aa3c57 on why this is the case.
gimp_int_radio_group_new() was still complaining about the scope of
radio_button_callback(). Make it (scope notified) because it needs to
stay alive after the function returns and may be called multiple times.
Also adding a GDestroyNotify to free the callback data once the widget
is destroyed (additionally it will also serve as a notifier for bindings
to properly free the callback closure itself, not only it's data).
With this last one done, GObject Introspection generation now happens
without any warning output.
When the "Omit hidden layers and layers with zero opacity" option is
set, this property was only checked on non-group layers. So if we had
non-hidden layers inside hidden layer groups, they ended up exported,
which is not the expected behavior.
See https://gitlab.gnome.org/GNOME/gimp/issues/4425#note_675350
Adds a new PDF export option "Convert text layers to image", which
defaults to FALSE (because text staying text is obviously usually
prefered).
Also loop through text layers to detect missing fonts. In case any are
found, add a warning in the export dialog, below the new option,
advising to enable this option if design matters (if fonts are missing,
PangoCairo seems to select any other random font and embed it into the
PDF instead of the expected one).