In some cases, non-English languages might appears first in current order.
and when having English name with non-English language ID like Google Noto CJK TC,
English name with English language ID will be dropped due to duplicate.
This fixes that issue.
Most of functionality should be moved to FcFreeTypeQueryAll()
for varfonts now though, if doing the same to FcFreeTypeQuery()
returns Null pattern because of inappropriate masking.
This might be not that big deal for varfonts support. but
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/162
Reported by Kevin Scott
'salt' attribute affects a cache filename to generate different name from directory name.
This is useful when sharing caches with host on sandbox and/or give a filename differently:
<dir salt="randomdata">/usr/share/fonts</dir>
<remap-dir as-path="/usr/share/fonts" salt="salt for /usr/share/fonts on host">/run/host/fonts</remap-dir>
Applications can read caches as-is for fonts on /run/host/fonts where is mounted from host.
and write a cache for their own fonts on /usr/share/fonts with different name.
The UUID files would be placed in each font directory to provide the
unique cache name, independent of path, for that directory. The UUID
files are undesireable for a couple of reasons:
1) They must be placed in the font directories to be useful. This
requires modifying the font directories themselves, introducing
potential visible timestamp changes when running multiple
applications, and makes the cache processing inconsistent between
applications with permission to write to the font directories and
applications without such permission.
2) The UUID contents were generated randomly, which makes the font
cache not reproducible across multiple runs.
One proposed fix for 2) is to make the UUID dependent on the font
directory path, but once we do that, we can simply use the font
directory path itself as the key as the original MD5-based font cache
naming mechanism did.
The goal of the UUID file mechanism was to fix startup time of
flatpaks; as the font path names inside the flatpak did not match the
font path names in the base system, the font cache would need to be
reconstructed the first time the flatpak was launched.
The new mechanism for doing this is to allow each '<dir>' element in
the configuration include a 'map' attribute. When looking for a cache
file for a particular directory, if the directory name starts with the
contents of the <dir> element, that portion of the name will be
replaced with the value of the 'map' attribute.
Outside of the flatpak, nothing need change -- fontconfig will build
cache files using real directory names.
Inside the flatpak, the custom fonts.conf file will now include
mappings such as this:
<dir map="/usr/share/fonts">/run/host/fonts</dir>
When scanning the directory /run/host/fonts/ttf, fontconfig will
use the name /usr/share/fonts/ttf as the source for building the cache
file name.
The existing FC_FILE replacement code used for the UUID-based
implementation continues to correctly adapt font path names seen by
applications.
v2:
Leave FcDirCacheCreateUUID stub around to avoid removing
public API function.
Document 'map' attribute of <dir> element in
fontconfig-user.sgml
Suggested-by: Akira TAGOH <akira@tagoh.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This saves the value of FONTCONFIG_SYSROOT in the config instead of
having to call getenv every time we need this value.
This also uses 'realpath' to construct a canonical path to sysroot,
eliminating symlinks and relative path names.
Signed-off-by: Keith Packard <keithp@keithp.com>
Otherwise, there would be build errors in the following 2 cases:
* define HAVE_POSIX_FADVISE
Or:
* undef HAVE_POSIX_FADVISE
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
This fixes the sort of weird things like `fc-match :size=rgb` done without any errors.
This might be annoyed but the error messages should helps to fix an application bug or
suggest more useful constant names to fontconfig.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/137
"color" property has a value more than 1 because the value of FT_HAS_COLOR
is directly set to it. this seems breaking the behavior of FcFontList with FC_COLOR=true
because it is more than FcDontCare.
So changing comparison that way.
Because FcDirCacheDeleteUUID does not reset the modification time on
the directory, and because FcDirCacheRead unconditionally creates the
UUID file each time it is run, any empty directory in the cache will
get its timestamp changed each time the cache for that directory is
read.
Instead, just leave the UUID file around as it is harmless.
The alternative would be to only create the UUID file after the cache
has been created and the directory has been discovered to be
non-empty, but that would delay the creation of the UUID file.
Signed-off-by: Keith Packard <keithp@keithp.com>
Akira TAGOH
Egmont Koblinger
Keith Packard
Robert Yang
Behdad Esfahbod