Sometimes fonts has multiple values in family and sub-family in order to unify
other variants into one. they basically make difference in sub-family though,
they also still have standalone family and sub-family. in that case, sub-family is
likely to be Regular.
fontconfig couldn't recognize the difference between :family=Foo:style=Regular
and :family=Foo Caption:style=Regular for example because fontconfig didn't
give different score on matching result for the position of multiple values in
a cache.
Thus, when querying a font like :family=Foo:style=Regular may results
:family=Foo Caption:style=Regular. (see the test case for more details)
To fix this situation, giving different score according to the position
of multiple values in a cache as well as the position of multiple values
in a query.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/283
Any early out checks must give the same answer as FcConfigCompareValue.
An accelerator was added for family names which treated all ops as if
they were FcOpEqual, giving the wrong answer for other non-equivalent ops
(for example FcOpContains or FcOpNotEqual).
This adds a test which passes before the accelerator was introduced,
fails after, and will pass again after !142 lands. This tests the all
not_eq case.
The test-conf test requires libjson-c to be available in order to be
built. However, there has been no user indication that additional tests
could be built if the json-c development files were available.
Continue to not build test-conf if json-c is not available, but do run
the test harness. The test harness is updated to SKIP the test if the
test-conf binary is unavailable.
cachedir is used to determine where cache files are stored.
the empty directory will ends up to put them under the top of
directory of XDG_CACHE_HOME. that messes it up and must be avoided.
As a note, if you want to read/write something from the top of
XDG_DATA_HOME (dir) and/or XDG_CACHE_HOME (cachedir),
put "." instead of the empty.
https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/180
Currently it fails if the executable extension is .exe, but wine isn't
available (e.g. on Cygwin)
Possibly the check to use this wrapper should be even more restrictive
e.g. checking if cross-building and/or if wine is available.
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>
Our test case relies on the outcome of the family property from freetype though,
it was changed in 2.7.1:
- PCF family names are made more `colourful'; they now include the
foundry and information whether they contain wide characters.
For example, you no longer get `Fixed' but rather `Sony Fixed'
or `Misc Fixed Wide'.
https://bugs.freedesktop.org/show_bug.cgi?id=47704
Prior to the change of 32ac7c75e8
FcConfigAppFontAddFile() always returned FcTrue no matter what
fonts was added. after that, it always returned FcFalse because
adding a font doesn't add any subdirs with FcFileScanConfig().
so changing that to simply ignore it.
Also fixing it to return FcFalse if non-fonts was added, i.e.
FcFreeTypeQuery() fails.
https://bugs.freedesktop.org/show_bug.cgi?id=89617
TESTS_ENVIRONMENT is deprecated and should be reserved to the user to
override the test environment
<ext>_LOG_COMPILER is meant to contain the program that runs the test
with <ext> extension
LOG_COMPILER is for extensionless tests
AM_TESTS_ENVIRONMENT is meant to set the environment for the tests
https://bugs.freedesktop.org/show_bug.cgi?id=60192
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
This reverts commit 2146b0307a.
That change introduces incompatibility and seems not working with
older releases of automake, including automake 1.12.2.
TESTS_ENVIRONMENT is deprecated and should be reserved to the user to
override the test environment
<ext>_LOG_COMPILER is meant to contain the program that runs the test
with <ext> extension
AM_TESTS_ENVIRONMENT is meant to set the environment for the tests
https://bugs.freedesktop.org/show_bug.cgi?id=60192
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>