They don't change of course, but this allows us to bind them in UIs

use G_MAXUINT32 rather than UINT32_MAX to avoid build error on Windows

See merge request GNOME/pango!702

Check whether we have DirectWrite support in our HarfBuzz installation if
Cairo is built with DirectWrite support, or otherwise check whether HarfBuzz
has GDI support enabled, as:

* We could use a simpler code path if HarfBuzz contains the needed support,
  which, sadly, is not enabled by default.
* Try the best to match what we will be using in Cairo when we create the
  hb_face_t for Pango, so if Cairo supports DirectWrite, we use DirectWrite
  for the hb_face_t if the HarfBuzz build supports that, otherwise we use
  GDI (like what we are doing now).

If we are building HarfBuzz as a fallback subproject, enable DirectWrite and
GDI support, since the Windows SDK (or mingw-w64) should supply the needed
items.

...if the HarfBuzz build has the applicable Windows-specific APIs enabled. This
will simplify the codepath that is needed to create the hb_face_t for Pango
that we need.

Since the former method to create the hb_face_t in PangoWin32 appeared before
HarfBuzz added GDI support, and we only supported DirectWrite in Pango later,
only build the old code when neither DirectWrite nor GDI support in HarfBuzz
is found/enabled.

In ac4d8f29, we switched from using
GTask to using explicit threading for our fontconfig
calls, since GTask assumes a mainloop and leaks memory
otherwise. But now we are creating a new thread for
every single fontconfig call, which is a bit excessive.
As a compromise, create a single fontconfig thread
per fontmap, and use an async queue to send fontconfig
calls to that thread.

Just use a single fontconfig thread

See merge request GNOME/pango!704

PangoWin32: Use HarfBuzz platform APIs if possible

See merge request GNOME/pango!701

This was a topic of discussion recently,
so clarify the current stance.

Sent the async queue already reffed, instead of hoping that the
new thread gets around to do the ref() in time.

Related: #768

Avoid a race

See merge request GNOME/pango!705

Normally, when Pango wraps a line after a space character, the space
character itself is said to be collapsed, and is not counted towards
the width of the line. This is implemented by adding a negative width
adjustment (extra_width). This has been implemented in commit
86303ad2
"Handle break-after-space correctly", and a few follow-up fix-ups.

There is a corner case: when the space we're trying to break at is the
last character in the paragraph, it should not get collapsed. This has
been implemented in commit 8ba98271
"layout: Fix a cornercase of line width accounting". However, due to
parts of the logic being duplicated in different places, that patch
forgot to update some of those places. Fix that by not collapsing the
space width in the other parts of the logic too.

In practice, this manifested as a Pango layout reporting to be wider
than its explicit width limit (layout->width), because the final space
was counted as collapsed (negative extra_width) when deciding whether to
break the line, and as uncollapsed when measuring the resulting line
width afterwards. That was in turn causing issues in GTK, where a
GtkLabel widget would get confused because of this fact, and report an
incorrect minimum width, and that, in turn, would be breaking
assumptions in the layout machinery several layers up in the widget
tree.

Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>

Adapted from a real-world case, the content warning of
https://lea.pet/notes/9lc92xktj5dq3w02

 that was breaking layout in the
Tuba app.

Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>

Count last-item space toward line width in more cases

See merge request GNOME/pango!706

If we have the dwrite_3.h header, first create the IDWriteFactory3 object,
which is available from Windows 10 or later, and grab the
IDWriteFactory5 object (available since Windows 10 Creators' Update) and
the original IDWriteFactory object from it, if we succeeded in doing so.

If we don't have dwrite_3.h (or IDWriteFactory3 from the system), create
the IDWriteFactory object as we did before.

Extend the fontmap populate function a bit so that if we have added
custom DWrite font sets to the IDWriteFontSetBuilder[1] in our font map,
we could add them to the font collection that we obtained from
the system.

Note that this does not yet expose any public API for people to use to
add font files to the fontmap for Windows.

We want to support loading custom fonts into a fontmap using DirectWrite
APIs in place of using AddFontResourceEx(), which DirectWrite will have
problems using if the FR_PRIVATE flag is being used in the call.

This way, we can just call the function directly if we already have an
IDWriteFont object, instead of going around for obtaining a LOGFONTW from the
IDWriteFont, and then re-obtaining an IDWriteFont object.

We want to reuse tearing down the items in our PangoWin32FontMap as we
are going to support loading custom fonts that are supported by
DirectWrite.

Also make the prefix for our font map object boilerplate
pango_win32_font_map instead of _pango_win32_font_map.

This is modelled after the PangoFcFontMap's implementation, where we
clear out the font map and reload things with new fonts that are added
via IDWriteFontSetBuilder(1), and emit the necessary signal and
notifications, to be used when pango_font_map_changed() is called.

This adds an API for PangoWin32 to add a font file that is supported by
DirectWrite into the PangoFontMap, for Windows 10 and later.

If DirectWrite is able to load and gather the info on the font file, put it
into the PangoWin32FontSetBuilder member (that wraps IDWriteFontSetBuilder/
IDWriteFontSetBuilder1) member of the fontmap, and then inform using
pango_font_map_changed() which will call the private API in the previous
commit, which will cause the font map to be reloaded with the system font
collection plus the font file(s) that were passed in via this API, with the
needed signals and notifications sent.

The fontmap->changed() vfuncs for PangoWin32/PangoCairo(Win32) is updated
accordingly, for this reason.

Support for Windows 7/8.x would probably be added later, pending demand
for such support.

...and also update some of the info as appropriate, such as the required Meson
version, supported build arch and the dependency requirements.

This will make the Windows build instructions easier on the eye.

Add sections so that one can find info on dependencies easier, and give a
better outline on how PangoFt2 can be built on Windows, especially when Pango
is built from scratch (i.e. without any dependencies found other than the
toolchain and/or Windows SDKs).

Suggested by Mashpoe Dev from issue #774.

Windows: Add API to load uninstalled fonts into fontmap (for Windows 10 and later)

Closes #720

See merge request GNOME/pango!700

Improve Windows build documentation

See merge request GNOME/pango!708

We want to add some commonly used items for using DirectWrite (i.e.
C++) in a new private header, so that DirectWrite code can use this.

This includes:
 * A release and an addref implementation that checks whether the
   object is NULL and act accordingly.
 * Structure that contained DirectWrite objects in
   pangowin32-dwrite-fontmap.cpp is now here.

This adds an implementation of loading fonts from some specified path for
Windows 7/8.x, to complete the feature that was already added for
Windows 10 or later.

To make things cleaner, this uses some more C++-specific items that
wraps the COM interfaces that we need to implement in this case,
especially that DirectWrite stuff already needs to be done in C++ when we
are using the Windows SDK.

Windows: Add API to load uninstalled fonts into fontmap (For Windows 7/8.x)

See merge request GNOME/pango!707

We now always find HarfBuzz via pkg-config, so just always include it directly
under `Requires` in the generated pkg-config file.

Fixup the names that we pass into looking for the FreeType dependency, and
ensure that the pkg-config file for PangoFt2 is generated with the correct
FreeType entry as it could have been found via pkg-config or CMake.

We now only look for FontConfig via pkg-config files, as FontConfig nowadays
can be built quite easily on Visual Studio using Meson, which will generate
pkg-config files for us.

Cairo 1.17.x is now built on Visual Studio using Meson, meaning that pkg-config
files are always around, plus 1.17.x contained many improvements, fixes and
features for Windows, so let's just limit looking for Cairo using pkg-config or
subprojects.

If we are building PangoFt2, also always check that Cairo contains FreeType and
FontConfig support (cairo-ft may or may not contain FontConfig support), or
if building Cairo as a subproject, build it with FreeType and FontConfig
enabled.

Consequently, this will simplify our checks on features that are enabled in
Cairo.

As we are using more of DirectWrite in PangoWin32, it makes sense for us to use
hb-directwrite also when we are (unlikely) not enabling Cairo support for the
build, to reduce differences that may arise when we use GDI interop in this
process.

So, from this point, we use hb-gdi (or its raw form) only when we are enabling
Cairo support and do not have DirectWrite enabled in the Cairo build, or
HarfBuzz is built without DirectWrite support.

...when one or more of them is being built as subproject(s). This will:

* Ensure that FreeType support is enabled for HarfBuzz if building PangoFt2
* Ensure that FreeType does not build with HarfBuzz support if HarfBuzz is
  also built as a subproject, so that things will build and link properly.

Building FontConfig support with Cairo, HarfBuzz and FreeType as subprojects
has been simplified in the build files, so let people know that options for
building these will no longer need to be specified for configuring the build.

Make the order of the enum values match the order in cairo,
otherwise casting goes badly. This bug must have been around
for decades :(

viewer: Make hint-metrics values match cairo

See merge request GNOME/pango!714

Clean up build files

See merge request GNOME/pango!709

family: expose name etc as properties

See merge request GNOME/pango!699

When serializing font descriptions, format the font size only
to the number of decimals needed to reconstruct the same Pango
units.

Code inspired by similar facilities in fonttools.

Affected tests have be updated.

Improve formatting of font sizes

See merge request GNOME/pango!717

This is a new api to go from a font to a modified copy and be
somewhat efficient about it. The modified font will be identical
to the original in all respects except possibly for size,
variations and cairo font options.

Test included.

Add pango_font_map_reload_font

See merge request GNOME/pango!716