CMYK profile is now stored in GimpImage on load
(rather than being discarded) and it's used for export rather than
the default simulation profile stored in Preferences
libxml has a XML_PARSE_HUGE parsing option, which can be turned on with
the RSVG_HANDLE_FLAG_UNLIMITED option in librsvg.
We cannot just set this option by default because it is a security
hazard as a maliciously malformed SVG could use this to consume too much
memory.
Instead, let's just propose the option interactively when we fail to
create a rsvg handle. Unfortunately right now we can't single out this
specific error because librsvg actually returns an unrelated (false
positive created by the huge data) error. So we just propose the option
for any kind of handle creation failure.
Furthermore, the option is only available on interactive plug-in calls
so far. In particular, the PDB API doesn't have an option allowing a
script writer to run "file-svg-load" with the huge data option.
As for the thumbnail API, it is never meant to be used interactively and
not really as a common script function, so it won't have the huge data
option either.
gimp_color_config_get_simulation_color_profile() is returning a new
object, so we had 2 code paths giving either allocated data or not.
Therefore simply ref the passed softproof profile in the second code
path, and don't ref it anymore when caching it (especially as it might
also be NULL at that point).
Now that images can contain their simulation profile,
we can use gimp_image_set_simulation_profile() to retain
the CMYK profile when a TIFF image is loaded.
It will then be accessible in GIMP's Image menu.
Adds support for saving 8 and 16 BIT CMYK/A TIFF files using the
image's simulation profile. If no profile or a non-CMYK profile
is set for the simulation profile, naive conversion is used instead.
The Makefile.am was apparently updated by hand in !662.
Also fixing plug-in label and doc localization, since this changed
recently and must now be localized directly on plug-in side.
langinfo.h is not on all systems apparently and/or the locale item we
test for may not be available everywhere. Actually even on Linux, after
testing more deeply, I could create cases where nl_langinfo() would not
return a result (if the locale is broken through environment variable
for instance). setlocale() seems to always return usable value so far,
so I fallback on it. As a last resort, I look at environment variables
(even though these may contain invalid contents.
As for Windows and macOS, I try to use more platform-specific methods.
In macOS in particular, as I understood from reports, GIMP follows
correctly the language preference order, which means we should not look
at a single (top) lang, but at the whole list of prefered languages as a
single settings to determine whether the language was changed or not.
Should fix on Windows:
> fatal error: langinfo.h: No such file or directory
and on macOS:
> error: use of undeclared identifier '_NL_IDENTIFICATION_LANGUAGE'
These files seem to have appear ever since the recent gettext changes in
commit f663d26ab5.
In particular, the call to autoreconf seems to be creating these.
This reverts commit 82f9ae1ab7.
This is not needed anymore. Cf. previous commit which implements the
force-requery differently and much more widely based on actual language
being stored and compared between runs.
Since localization is fully handled plug-in side now (see #8124), we
need to make sure the query functions are run again for all plug-ins
when the UI language changes (otherwise we might end up with
localizations from the previously used languages).
We were already reloading plug-ins when explicitly changing the lang in
the Preferences, but this new implementation is much better as it's
generic. In particular, it will also handle the case when the system
language changes (or when you play with locale environment variables).
This removes rate limiting of ruler and statusbar updates which were
required to get acceptable performance on mac for drawing on the canvas.
This requires the latest changes on in Gtk 3.24 to be incorporated.
Continuing the changes in #8124, let's have properties labels and blurbs
both localized on plug-in code, i.e. with gettext calls directly in
GIMP_PROC_ARG_*() calls.
Note that it was already the case for blurbs (longer description,
tooltip) as I couldn't find code where we'd localize it further down the
line. But we were running gettext on nicks (shorter description, label)
inside GimpProcedureDialog code. Let's not do this anymore.
This will make the whole localization much more clear and obvious. There
is no "later localized" case anymore. Now let's localize everything
directly when the arguments are created.
Jehan