Stripping the first char of a path to make it relative only works with
UNIX paths like '/prefix' but not with Windows paths like 'c:\prefix'.
This copies the code Meson uses.
Previously, requesting a monospace font with an invalid font family
(for instance, when a font is not embedded in a PDF, poppler may
issue such queries), the font family would be filled by configuration
file 49-sansserrif.conf with sans-serif
This new rule set the family to monospace if spacing=100 is specified
in the query.
sysconfdir defaults to /etc when the prefix is set to /usr. But joining
MESON_INSTALL_DESTDIR_PREFIX and sysconfdir when the latter is an
absoulte path, results in sysconfdir only. Which might lead to an error
during install because /etc/fonts/conf.d/ might already exist from an
pre-existing fontconfig installation.
In Makefile, we are trying to remove old symlinks first and then create a symlink.
do the same thing in meson too.
Also, the line of the exception handling for FileExistsError is meaningless
as the above line is taking care of it instead and we shouldn't ignore it if
os.remove and os.symlink doesn't work somehow.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/275
XML tools interpret “fonts.dtd” as a relative path.
Unfortunately, that can not work now that the configuration is spread over
multiple system-dependant directories, without a common relative path to this
file. And, an absolute path can not be defined in a system-independant way.
System independance is a requirement to share config files between systems.
Therefore, replace the broken relative path by a formal URN, that will work the
same way on all systems, without network access.
This makes the DTD registerable with commands like:
$ xmlcatalog --noout --add system \
"urn:fontconfig:fonts.dtd" \
"file:///usr/share/xml/fontconfig/fonts.dtd" \
/etc/xml/catalog
That enables easy config file checking:
$ xmllint --loaddtd ${config_file} >/dev/null
This avoids a situation where the score of lang becomes lower or equal to others
and then figures out the best font according to other properties and the order
of family names.
This typically happens only when our orthography files are the subset of lang
in patterns. i.e. fc-match :lang=en-us to match on en.orth.
In this case, the score is lower than the exact match (en to en) and the partial
match (en to en-us). thus, the result of 'fc-match :lang=en-us' isn't necessarily
same to 'fc-match :lang=en'.
So 35-lang-normalize.conf contains languages only which is available as orth
without countries and tries to update properties to match on orth exactly like:
<match>
<test name="lang" compare="contains">
<string>en</string>
</test>
<edit name="lang" mode="assign" binding="same">
<string>en</string>
</edit>
</match>
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/155
The generic family of 'system-ui' name is being proposed in a draft of next CSS Fonts.
This would be nice to support in fontconfig too.
https://www.w3.org/TR/css-fonts-4/
Trying to address what these configuration files really do.
This change allows to see the short description that mention
the purpose of the content in the config file and obtain
them through API.
This change also encourage one who want to make some UI for
the user-specific configuration management. it is the main
purpose of this change for me though.
Aside from that, I've also made programs translatable. so
we see more dependencies on the build time for gettext,
and itstool to generate PO from xml.
Prefer the system provided emoji fonts on systems which provide one,
such as Windows, MacOS and Android, even if the Emoji One or Emoji Two
fonts are installed.
This also allows free software OSes such as GNOME to prefer the Emoji
One font, which is not used in other OSes and therefore has a unique
brand identity, by installing them and only them by default.
Users can use more capable fonts while Emoji One and Emoji Two catch up
by installing a font otherwise already used by another system, such as
Google's freely redistributable Noto Emoji font.
https://bugzilla.redhat.com/show_bug.cgi?id=1496761
Old logic was really bad. If you requested weight=102 and got a medium
font (weight=100), it would still enable emboldening...
Adjust it to only embolden if request was >= bold and font was <= regular.
Seems to work now. Either asking for family emoji, or :lang=und-zsye returns
the preferred color emoji font available, or just any color emoji font if none
of the preferred ones was found.