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)
Note that I marked the news as releasing on the 29th though the release
is marked for 28th, because we never manage to release the web news on
the same day, and usually we wait for the Windows and/or macOS
installers at least.
The saved value for Iptc.Application2.Caption is copied from Xmp.dc.description.
However the last one is multiline but the former should be single line. This
caused only the first line to be saved instead of all lines.
To fix this we set Iptc.Application2.Caption to single and use a different
conversion based on whether the tags from Xmp and Iptc are both
multiline or whether Iptc is single line.
(cherry picked from commit 5d14c59d2e)
While testing the metadata-editor I noticed that certain values for
ModelReleaseStatus and PropertyReleaseStatus were incorrectly
read back.
Apparently while copy pasting some values were forgotten to be
updated which caused incorrect values to be saved.
There probably are not many users of these metadata tags
since in all these years there hasn't been a bug report about this.
(cherry picked from commit 93f591931b)
The metadata-editor allowed Iptc tags to be set if an empty string was
used contrary to Xmp tags. In the case of DateCreated this cause an
invalid date "0-00-00" to be written.
We added a check to only write text Iptc metadata if the value is
not empty.
(cherry picked from commit 0a902456ac)
Fixes issue #3656 Empty metadata tags are written to XCF at least.
Xmp.plus.ModelReleaseStatus and Xmp.iptcExt.DigitalSourceType are
defined as combo boxes with a fixed number of possible values.
However there was no option to leave it empty so there always was
a value written when saving metadata in the metadata-editor.
We added a "select value" as default option and only write
metadata if a different value was chosen.
As a bonus we replaced the fixed loop numbers with
the current actual number of defined choices.
(cherry picked from commit a229454915)
Since version 0.27.3 exiv2 has changed how it returns
comments for Exif.Photo.UserComment. We now get
the comment including the charset=Ascii value.
Let's remove anything that's not part of the actual
comment. To not complicate things we will only
handle charset=Ascii for now since I've never seen
any other charset used.
(cherry picked from commit 352b5885b1)
# Conflicts:
# libgimp/gimpimagemetadata.c
1. Convert xmp /Iptc4xmpExt tag parts to /iptcExt because
exiv2 fails when we try to use the default namespace.
2. Don't only set structs from a fixed list but find all
xmp array elements and check what the best struct
type is: bag or seq.
3. Work around a sorting issue in (g)exiv2 by using a natural
sorting algorithm ourselves.
4. Added some g_debug statements to make it easier to
determine the cause of issues.
We need to work around an issue in Exiv2 that saving to /Iptc4xmpExt bag
records fails which seems related to it registering /iptcExt. Unregistering
that and registering the first one doesn't work.
See: https://gitlab.gnome.org/GNOME/gexiv2/-/issues/24
So let's use /iptcExt for saving even though it's the less common form
for now. When loading metadata we try to load the most common
form first and if that fails we will load /iptcExt.
(cherry picked from commit a95371c2b0)
Set Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:* last since the short
form Xmp.iptc.Ci* could have been used to set this information too.
Becausethe first (longer) form is the most common let that override the
shorter form in the (unlikely) case that both are present and also have
different values.
Due to a bug in the metadata-editor previously only the short form
was saved.
(cherry picked from commit d00fe2bfe2)
Reordered the strings in artworkorobject to be in the same
order as the columns.
Add write_metadata_tag_multiple function that handles most
of the previously duplicated code and check for special
handling of phonetype when necessary by adding
an enum and a get_phonetype function.
(cherry picked from commit 4609def72f)
Use a separate function that can be reused and also get rid of
the large output_data array and strcat without length
checking. We will use GString instead.
(cherry picked from commit 9c2451d813)
This removes some flawfinder warnings by not using a fixed
size array and using g_snprintf instead of g_sprintf and
using more safety checks.
(cherry picked from commit c2fa21ac7d)
There was a lot of duplicate code based on
whether or not value was NULL with for
some tags partially unreachable code.
We combine the parts and only test
value for NULL where needed.
Also rename the typos in enum
COL_REGSITRY_* to
COL_REGISTRY_*
(cherry picked from commit 0a0eeac1ad)
There's a lot of duplicate code for adding string values
to the gui (liststore). This is another part of trying
to reduce that.
Besides that the copying code uses fixed size arrays
without length checking as pointed out by flawfinder.
We will instead use a function add_to_store to add a
comma or semicolon separated list of values stored in
value to add rows with values to the gui.
(cherry picked from commit e24a6dc8d6)
Crop tool used stale color / pattern values when performed crop with
'Allow growing' option. Its context was not notified when fg/bg/pattern
value was changed.
Closes: #4103
