New branch 'private/tml/I4bc6e32dcc32ff74b79679edacee1aecebd774c7' available
with the following commits:
commit 823d8ec0d9281dbd2c12362bedd8d9ef6145a99f
Author: Tor Lillqvist <[email protected]>
Date: Tue Dec 30 16:25:06 2025 +0200
Make also fonts installed from the Microsoft Store show up in CODA-W
This was much more complicated than expected. Most of that thanks to
the inscrutability of fontconfig.
Fonts from the Microsoft Store get installed in a separate folder per
product, under the WindowsApps folder. Each such font product folder
contains one or several TrueType font files, and metadata files, and
preview images, etc.
Add a C++ source file to fontconfig that uses DirectWrite to enumerate
the available fonts. Take only those with a source type of
DWRITE_FONT_SOURCE_TYPE_APPX_PACKAGE into account. Other fonts are
found as before, looking in the system fonts folder (typically
C:\Windows\Fonts) and in the per-user fonts folder (typically
C:\Users\username\AppData\Local\Microsoft\Windows\Fonts).
This C++ code requires headers from the winrt tree in the Windows SDK,
so add that to SOLARINC.
Sadly, thanks to the way fontconfig works (scanning directories for
font files), I need to let it scan the folders of font products from
the Microsoft Store to find the font files, even if the DirectWrite
API would already give us the font file names directly. But I didn't
want to modify fontconfig too much, so oh well.
There was something weird in how fontconfig calculates the hash for
directory names to be used in its cache files. It ended up creating
more and more cache files for the same directories each time CODA-W
was run. I could not understand what was going on, but in any case,
just making sure that FcConfigMapFontPath() and FcConfigMapSalt()
don't do anything on Windows seems to help.
Also change the way freetype is built so that only the special
FT_Done_MM_Var is exported, not all pubic functions. This was
necessary because for some unknown reason, when linking the vcl DLL I
started getting errors for the freetype symbols that happen to be
linked into also the cairo DLL. If we eventually can switch to
building all of core statically for CODA-W this problem will go away.
There is still much to do to make fontconfig (and probably freetype
and cairo) work really correctly on Windows. The most obvious thing is
that the file name handling is broken. This is perhaps understandable
as the port of that code to Windows is from over 20 years ago, I
think.
It works for file and folder names in ASCII, but most likely not for
others. At least the user profile directory, under which per-user font
files are stored, will definitely have non-ASCII in many cases. We
should modify the code to use <tools/UnixWrappers.h>, so that all file
system access is done using proper wide character (UTF-16)
APIs. Pathnames that these libraries handle will then be in UTF-8. The
opendir() etc emulation in fontconfig should also be replaced by
adding such to UnixWrappers.h instead.
Signed-off-by: Tor Lillqvist <[email protected]>
Change-Id: I4bc6e32dcc32ff74b79679edacee1aecebd774c7
