… description.
- The returned value as width/height/etc. of the glyph extents (or bounding
box), not "of the font" (which doesn't mean much).
- Adding some definition for ascent and descent. This text is straight out
copied from Pango documentation comments in pango/pango-types.h.
- I don't see why we were negating the descent value. Let's keep the value sign
as defined in Pango.
- Fonctions were renamed: s/gimp_text_fontname/gimp_text_font/ and
s/gimp_text_get_extents_fontname/gimp_text_get_extents_font/
- The size_type arguments were removed. Even in 2.10, this argument was marked
as "dead" and ignored. It was only kept for API compatibility.
- The font name (string) was replaced by a GimpFont argument.
gimp_text_font() is easily tested in the Python console with:
> Gimp.text_font(Gimp.list_images()[0], None, 10, 40, "Hello World!", 1.0, True, 100, Gimp.context_get_font())
And gimp_text_get_extents_font() with:
> Gimp.text_get_extents_font("Hello World!", 100, Gimp.context_get_font())
This fixes 2 issues:
1. gimp_scanner_parse_string() may fail, which here would indicate broken input.
If it does, the string variable would not be set, so we need to initialize it
to NULL, otherwise freeing it could crash GIMP.
2. The variables set by gimp_scanner_parse_string() must be freed.
While I was testing some fonts I had on my system which were named exactly the
same, I also realized that all their fields were identical (among the ones we
store at least), except for the hash obviously. While the hash is great to
differentiate fonts when we use exactly the same files, there are various
reasons where one could have the right font installed with a different hash
(e.g. a simple reason could be if it was stored in different font formats).
So I'm thinking that maybe we'll want to add more fields in the future (if there
are any more fields allowing to better discriminate among some fonts named
similarly). This commit will allow this version of GIMP to still work when
loading the future serialized fonts with new and unknown fields. The unknown
fields will be ignored but at least it will still do its best to find fonts with
the known fields. Therefore we won't have to bump the XCF format version if we
only add new fields.
Similarly this allows to add the fields in-between, reorder existing fields or
even remove some in the future if we realize something is really unneeded. It's
less a big deal than the ability to add new fields without bumping XCF version
though.
Rather than looping fully over the full list of fonts once more, and
re-computing a second time the same font similarity score (with the risk of
messing up the copy-paste), let's just store the indexes of "most similar" fonts
in the first loop, then only query and check the hash for these.
This is not the main reason for the specific output in #9994. These ones are
more probably because of similar usage in GTK (which updated its own calls to
g_file_info_get_is_hidden|backup() in version 3.24.38). But we should likely
also update the various calls we have to use the generic
g_file_info_get_attribute_*() variants.
To be fair, it is unclear to me when we can be sure that an attribute is set.
For instance, when we call g_file_enumerate_children() or g_file_query_info()
with specific attributes, docs say that it is still possible for these
attributes to not be set. So I assume it means we should never use direct
accessor functions.
The only exception is that I didn't remove usage of g_file_info_get_name(),
since its docs says:
> * Gets a display name for a file. This is guaranteed to always be set.
Even though it also says just after:
> * It is an error to call this if the #GFileInfo does not contain
> * %G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME.
Which is very contradictory. But assuming that this error warning was
over-zealous documentation, I kept the direct accessors since they are supposed
to be slightly more optimized (still according to in-code documentation) so
let's priorize them when we know they are set for sure.
- g_str_equal() doesn't have the proper signature for g_slist_find_custom() so
current code was never processing multiple subfonts in a markup layer text.
- Escape the font name parsed from the XCF. For old XCF format, it could contain
forbidden characters. And even for new XCF files (with fonts names generated
such as 'font123' so there should be no escapable characters), we should not
trust that the XCF/parasite contents is correct. It can be wrong for various
reasons.
- Search for ' font="%s"', otherwise the search-and-replace might catch other
XML attributes. For instance we don't want the font "ultrabold" to match
weight="ultrabold".
- The backward compatibility code didn't have code to stop 2 font name
replacements to chain up, i.e. if a real world font was named "gimpfont123"
and another "gimpfont321" and if our replacement code were to change
"gimpfont123" to "gimpfont321" then "gimpfont321" to something else. In the
end, we'd have only a single font. I am fixing it by replacing " font=" to
" gimpfont=" then only correcting the attribute name at the end. This
intermediate attribute name acts as a "done" flag.
There are 3 fixes here:
1. First, searching for "\"GimpFont\"" to determine whether or not this is a new
format text parasite is not enough, because this string can be found in a
text layer with "GimpFont" only as contents. It will serialize as:
> (text "GimpFont")
Instead search for "(font \"GimpFont\"" which cannot be created as part of
the text contents because of the unprotected double quotes).
2. We must verify that strstr() did not return NULL when searching for markup
delimiters. It may happen if the parasite contents is invalid (we must always
assume it can be, since it's user data).
3. When deserialization of a text from parasite fails (e.g. because parasite
doesn't actually exist or its format is wrong), still make sure the GimpText
has a font (setting the standard one before deserializing). Otherwise GIMP
crashes down the line.
For this, I also had to fix gimp_config_deserialize_object(): the object type
name must be parsed even if an object was already set in a GObject property.
The new parasite format cannot be loaded by old versions of GIMP. This means we
must bump the XCF version (even though technically we didn't really touch the
XCF format itself because text layers are stored in a hackish way, yet text
layers are just too important nowadays to not care).
Nevertheless if an old XCF with text layers was loaded and the text layers left
untouched, the old parasite will be saved back as-is. Therefore no need to bump
the XCF version in this specific case. Only when we created new text layers or
edited existing ones.
Previous code was incrementing the similar_fonts count each time we found a
better candidate. So we ended up computing the hash even when we had only 1
candidate with maximum similarity.
Moreover this commit fixes a crash happening with the "standard font". The
lookup name must always be allocated, even when it's an empty string (otherwise
it crashes at free).
Additionally this commit factorizes the code so that gimp_font_get_hash() takes
care of hash computation instead of duplicating code.
Finally I do some code organization.
MR #1011 breaks that because now we have a display name
and a lookup name, so font info is saved in the xcf file,
and when loading, the font which matches these info is used.
This doesn't fix pango markup having the wrong fonts names.
In GimpText, The font used to be stored as a string containing its name,
Now, it is stored as a GimpFont object, which makes more sense and makes
operations on fonts easier (such as serialization).
to fix the issue when 'Standard' can be actual font from the list
or a font which starts with. (ie. Standard Symbols PS)
Fixes: #3104 (GNOME/Gimp tracker)
Some fonts which pango identifies correctly, became broken
after renaming them in fontconfig, so the strategy was to
rename only fonts which pango can't see.
To check if pango got the correct font, the PangoFont
has to be loaded from PangoContext, which is costly.
It Turns out that querying FontConfig with more attributes
fixes this. Hence renaming every font doesn't affect
the fonts pango already sees.
We use fontconfig directly to rename fonts to fix some issues
with Pango (see MR !1011), and fontconfig is present on all
platforms supported by gimp (even on windows, pango is build with
fontconfig as a dependency), so it makes little sense to keep this
code path which is now never used.
(except from the aliases "Sans-serif", "Serif" and "Monospace")
The code to get the file path was inspired by code in MR !1011 by Idriss Fekir.
My initial idea was to use FcFreeTypeQueryAll() when adding each font
individually through FcConfigAppFontAddFile() but we were only doing this for
our additional directories (not the system ones) and also before we actually
loaded all the fonts through FontConfig. So this would have required more work
to get right. Though it also means that now the ! USE_FONTCONFIG_DIRECTLY code
path is more broken than ever (as we consider this path information quite
important for plug-ins now).
Additionally to make this work, I got rid of the code making all GimpFont
objects internal data by default, which is nonsense to begin with. Fonts are not
writable by GIMP, sure, yet they are external to GIMP and loaded from a file!
This will be important for an upcoming commit (which is currently in a branch
related to issues #50 and #9250), where we want to implement GimpResource
storage as plug-in settings, because fonts were the only GimpData without a file
and we are using this information to generate a collection identifier.
Note that there is a `container_obsolete` too in GimpDataFactory and I don't
apply the "unique-name" property to it because I'm unsure what it is.
Furthermore, eventually we'll want all types of data to allow duplicate names
(brushes, patterns or whatnot may come from all sources and may be named the
same by different people). But for now, let's focus on fonts before breaking
other parts of the codebase which we might not look into right now.
… the GIMP_DEBUG_FONTS environment variable is set.
Turns out nearly a thousand font files get ignored on my installation (and I
don't install much; a lot of them seem to be bitmap fonts (PCF) in a X11
directory). I still want output so that this topic doesn't get forgotten and
hopefully some day, we can do better. But a single line on stderr (and an
environment variable for details) is enough for now.
Remap font names to unique generated names
so that pango sees them.
keep the font name for display and the internal
name for everything else.
* Fonts are still broken When exporting to pdf
* Not sure if xcf files would be usable on other systems
maybe use hash of psname internally instead
* Not sure if plug-ins using text layer work correctly
(do they use internal font name or the actual name?)
Resolves issue with #8461.
This provides a conditional value for the fill options to only show
a color and pattern, rather than fore/background colors.
Currently only used for the text editor.
There was a bug in commit ca6b58e970 which went under the radar. The gimp
variable was not set at creation, so this line was crashing:
> container = gimp_data_factory_get_container (text->gimp->pattern_factory);
Replaces "Solid Colors" option in Fill Path with Foreground/Background
Colors options. This allows users to fill with either, rather than
having to switch the foreground color each time.
GIMP_CONTEXT_PROP_MASK_BACKGROUND was added to the fill and stroke
contexts to allow the background color to be recognized.
In places where Solid Color was used as a default, Foreground Color is
now used instead.
Loading an .xcf with a patterned outline caused GIMP to crash.
This is because PROP_GIMP was loaded at the end, so it was null when
text->gimp->pattern_factory was called. Moving PROP_GIMP to the
top of the property enum list ensures it's loaded first,
which resolves the issue.
This ports Massimo’s code to work in the latest version of GIMP.
It adds new outline-related properties to GimpText and GimpTextOptions.
These are controlled via the Text Tool Editor.
Cairo is currently used to draw the outline around the text.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
Generated *enums.c now have an additional stamp no-op header include
(see last 2 commits). Sync this change into the autotools generation
scripts to prevent back and forth useless generation of these files each
time we switch from one build system to another.
They are nearly the same as initially, except that now they include an
intermediate stamp header which will be generated by the build system.
The only 2 enums which don't need these includes (and are not versioned)
are libgimp/gimpenums.c and libgimpthumb/gimpthumb-enums.c.
Our meson build system was not properly building the enums.c file,
because they are versionned.
I did a similar trick as what I did for the pdbgen, which is that I used
a wrapper script around the existing perl script, which sets proper
options and generate a stamp file in the end (which is considered by
meson as the actual custom target, not the C file since it is generated
in the source dir).
The most important part is that the stamp file is a generated header
source (not just a random text file) which is **included** by the
generated C file. This is what will force meson to regenerate the C file
if the header is updated, **then** build using this new version, not use
an outdated versionned version (which would make for hard to diagnose
bugs), through the indirection of the intermediate stamp header.
See #4201.
See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
… and s/gimp_parasite_flags/gimp_parasite_get_flags/
It is better to have a consistent API and the fact is that most
getter/setter functions use the _get|set_ naming, but these didn't.
I wondered if this was such a great idea to rename these anyway because
even though we are breaking API in GIMP 3, is it the best idea to rename
when no functional change happened? After discussing with Wormnest, we
still agreed it was still better to go for consistency rather than
regret later (and be stuck with these names for many more years).
Also this fixes these warnings:
> [649/1205] Generating gimp-3.0.vapi with a custom command
> Gimp-3.0.gir:24162.7-24162.56: warning: Field `Gimp.Parasite.flags' conflicts with method of the same name
> Gimp-3.0.gir:24318.7-24318.52: warning: Field `Gimp.Parasite.name' conflicts with method of the same name
… apply to GIMP GUI not text layer rendering in image.
Reviewer note: this is the theoretical fix, but it won't work right now
because Cairo explicitly bypasses grayscale antialiasing when system set
subpixel one. Still let's push this first patch, but the issue will be
actually fixed when Cairo will merge my MR too:
https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/114
First of all, "CJK Unified Ideographs" block should not be the highest
priority to determine showing an ideograph. Indeed most fonts for a
Korean and Japanese audience would also contain at least the main
ideographs. So instead, look first for Korean alphabet (Hangul) and
Japanese syllabaries to determine if it's a Korean or Japanese-targetted
font. Only then Chinese.
Also check Korean before Japanese because most of the Korean fonts I saw
actually also include Japanese syllabaries (but not the other way
around).
This way, it will be much easier for CJK graphists to skim through the
font list and detect fonts made for the needed language in a glance.
Also modifying the Korean display text. KIYEOK and SSANGKIYEOK were
obviously chosen because they were the first in the block. But they are
very bad choice. We hesitated with 가 at first, as it is considered the
first in the syllabary form (가나다라 is kind of similar to our ABCD).
But it wouldn't show a form with a second consonant (below) which is a
good stylistic indication. So we hesitated between 한 (han) and 글
(geul, which also means text so it's a nice sample), and finally went
with 한 because of the circle shape in ㅎ (hieut) but also its small
"hat" which has many stylistic variants. So it's quite a good hint of
stylistic choices made by a font designer from just the sample box.
Moreover I switched the block check from "Hangul Jamo" to "Hangul
Syllables" block. "Hangul Jamo" are positional forms of the letters to
dynamically compose syllables (in particular legacy syllables not in use
anymore). Though a feature-full Korean font set would design these, it
is less important than "Hangul Syllables" (pre-composed syllables
design) or "Hangul Compatibility Jamo" (basically the same letters as
"Hangul Jamo" but for standalone usage). Also I actually saw some fonts
made for Korean without "Hangul Syllables" support.
Finally I also added a test for Japanese. I check the Hiragana block
which is most likely the most basic which has to be in any
Japanese-targetted font and use 'あ' (a) as sample text, which is the
first Hiragana syllable and here definitely a good sample text in my
opinion.
I believe that this can still be improved though. Checking only a single
block to determine the probable target language is not necessarily
enough. For instance very complete fonts for Chinese may also design
Korean and Japanese characters, but will also have most CJK blocks and
more ideographs (whereas Japanese/Korean will likely have less). Yet
let's say this is good for now, at least better than before!
pango_fc_font_lock_face() is deprecated since Pango 1.44.
This may hopefully also fix#5922 as I completely changed the code where
the CRITICAL happened. Yet I left g_return_val_if_fail() to check if the
Harfbuzz font and FreeType face variables are not NULL (because looking
at the code, it looks like these functions returning NULL actually means
there is a bug in the code).
Nevertheless if it turned out that there are non-bug cases where these
could return NULL (for instance a broken font file?), then probably we
should not use g_return_val_if_fail(), but instead address the data
issue in a nicer way.
Bumping harfbuzz dependency to 1.0.5 for hb_ft_font_set_funcs(). Without
configuring the Harfbuzz font with it, hb_ft_font_get_face() always
returns NULL.
Note that it looks like hb_ft_font_lock_face() would actually be better,
but this requires harfbuzz 2.6.5 from last April which is quite recent.
So let's just use the get_face() variant for now.
Additionally to loading the default fontconfig configuration file, GIMP
also looks up /etc/gimp/<version>/fonts.conf and
$XDG_CONFIG_HOME/GIMP/<version>/fonts.conf (or equivalent in other
OSes). If these don't exist (which is the most common case), this is not
considered a bug. Fontconfig had a regression bug of
FcConfigParseAndLoad() in 2.13.92, which was fixed in a later commit:
fcada52291
As a consequence of this bug, font loading failed in Windows when these
non-mandatory files were absent.
The current commit, originally proposed by Jacob Boerema (@Wormnest) and
slightly reviewed works around the issue, because anyway there is never
any reason why failing to load these files should break font loading as
a general rule. Even if these files exist and are broken (wrong syntax
or whatnot), we should just output some warning on stderr and continue
loading without these additional confs.
With fontconfig 2.13.92, warnings will be also outputted (wrongly), but
at least it won't block loading anymore.
Also let's unref() the `config` object even when the whole font loading
succeeds. Man of FcConfigSetCurrent() clearly says that the reference
count of config is incremented since 2.12.0 (our current minimum
fontconfig is 2.12.4) so let's not leak one reference.
You shouldn't rely on GObjects being `const`, since a reference count
operation does not respect that. That being said, this fixes a warning,
for a keyword that seems to be redundant here.
* 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.
More of the files were wrong, or at least not absolutely identical to
the files generated by the autotools. I am not doing any code change
other than trying to make both build systems produce identical files
(except for slight differences on 2 files not worth the effort) even
though maybe some things can be improved (especially on the include
list). Maybe to be improved later.
Also fixing 2 of the previously autotools-generated files because of
space typos which should have been committed earlier.
Finally it is to be noted that there is no logics to copy the generated
files back to the source directory in the meson rules. I am not sure
anyway this is really worth it and maybe we should just stop tracking
these generated files eventually.
Idriss Fekir