Setting variations to their default value causes
them to show up in the serialization of the font
description - a font description has no idea about
the default values, so can't filter them out.
Avoid that.
Rename README_EGL_MSVC.txt to README_FEATURES_MSVC.txt, as we now have
more features that can be included in the builds using the Visual
Studio projects, which require additional depedencies and manual
enabling.
Specifically, this outlines how the font tweaking feature in libgtk can
be enabled and for people who wish to do so, how to enable the Font
Features demo in gtk3-demo.exe.
...even if PangoFT2 is not present, provided that Pango 1.44.0+ and
HarfBuzz 2.2.0+ are installed. The demo now has added support for later
Pango versions that use HarfBuzz for shaping on all supported platforms.
...if Pango 1.44.0+ and HarfBuzz 2.2.0+ are available, otherwise we
stick on to the current code path.
This way, we can have people build and run the demo even without
PangoFT2 if Pango 1.44.0 or later and HarfBuzz 2.2.0 or later is
installed.
We can regenerate demos.h.win32 with or without the font features demo
by using the regenerate-demos-h-win32 target with or without secifying
the FONT_FEATURES_DEMO=1 flag on the NMake command line.
This way, we can share the demo listing to be used in other build
Makefile-based build systems, such as the auxiliary NMake Makefiles used
to generate the various sources.
...in the libgtk3 project, so that we can automatically link to
harfbuzz.lib if we have a sufficiently-new version of Pango and HarfBuzz
installed, so that the code to enable font features can be linked
properly, even if we don't explicitly put harfbuzz.lib in the list of
libraries that we feed into the linker in the project files.
If one is using pre-Pango-1.44.x and/or pre-HarfBuzz-2.2.0 and intends
to enable font features support, one still must update config.h.win32 to
make sure HAVE_PANGOFT2 and HAVE_HARFBUZZ is defined, and put
pangoft2-1.0.lib, harfbuzz.lib and freetype.lib (or so) in the
"Additional Libraries" under the linker settings in the projects
manually, as required before.
This is a backport of the code in GTK4 where we can use the font
features that is given to us via HarfBuzz if we have Pango 1.44.x and
HarfBuzz 2.2.0 or later installed, even if we do not have PangoFT2
aavilable.
Since Pango 1.44.x depends on HarfBuzz for all platforms after 1.44.0,
we could take advantage of that and build the support in
GtkFontChooserWidget.
Add a directive that is to be used by Visual Studio compilers via the
Visual Studio projects to link to harfbuzz.lib automatically, so that
this support can be linked properly if we have the required Pango and
HarfBuzz headers and lib's installed. Meson builds via Visual Studio
should handle this automatically, since pkg-config is being used there.
Since HAVE_PANGOFT2 and HAVE_HARFBUZZ is not defined by default in the
Visaul Studio projects, we will leave it up to the user to enable them
themselves and put in pangoft2-1.0.lib and harfbuzz.lib in the project
settings by themselves, or they could use Meson, as we did before.
When the compose file is a symbolic link, take the link itself's
modification time into account (in addition to its target's) in
determining whether to invalidate the compose cache.
This is useful e.g. on NixOS systems where the compose file might point
to a store path with an irrelevant modification time, and we want the
cache to expire when the symlink itself changes.
(cherry picked from commit 22f5236943)
Ping/pong serials are not meant to be interpreted as user input serials
(e.g. those given back later to the compositor on grabs). As a matter
of fact, Mutter uses a different count (i.e. timestamps) in these, so
using these serials may confuse the compositor into denying certain
operations like DnD.
In macOS-12.sdk CGContextConverSizeToDeviceSpace returns a negative
height and passing that to CGContextScaleCTM in turn causes the cairo
surface to draw outside the window where it can't be seen. Passing the
absolute values of the scale factors fixes the display on macOS 12 without
affecting earlier macOS versions.
Like the Visual Studio 2012+ projects, copy the Visual Studio 2010
projects and replace the items in there as needed, so that we can
obtain Visual Studio 2022 project files, since they are all in the
MSBuild format.