fontconfig issues
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues
2022-01-14T04:50:43Z
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/306
Synthetically emboldened raster font has its letters spaced too close
2022-01-14T04:50:43Z
SneedSoft
Synthetically emboldened raster font has its letters spaced too close
The automatically generated bold version of the raster font I'm using, while adds more weight to it, does not change letter spacing from the normal version, so the letters end up too close together.
There appears to be a "spacing" proper...
The automatically generated bold version of the raster font I'm using, while adds more weight to it, does not change letter spacing from the normal version, so the letters end up too close together.
There appears to be a "spacing" property in fontconfig. However, trying to alter it with a .conf file doesn't seem to do anything.
Here's the font I'm using and a .conf file I attempted to write:
[MSSansSerifRaster.otb](/uploads/c3da3a2b3002150ee4a1f4cefd61b81f/MSSansSerifRaster.otb)
[99-ms-sans-serif-bold.conf](/uploads/e1fd50183dae5e04350712b0939ac55c/99-ms-sans-serif-bold.conf)
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/303
Not all OpenType variations detected (Regression in version 2.13.94)
2021-12-09T11:41:32Z
Erik Arvstedt
Not all OpenType variations detected (Regression in version 2.13.94)
Since version `2.13.94`, fontconfig fails to detect all variations/weights for some fonts.
### Reproduce
```bash
# Download demo font
curl -L https://github.com/erikarvstedt/fontforge-bug-repro/blob/99490c7b5cedb965274e3306f8eb062b69577...
Since version `2.13.94`, fontconfig fails to detect all variations/weights for some fonts.
### Reproduce
```bash
# Download demo font
curl -L https://github.com/erikarvstedt/fontforge-bug-repro/blob/99490c7b5cedb965274e3306f8eb062b69577a27/SFNSDisplay.ttf?raw=true -o SFNSDisplay.ttf
fc-scan SFNSDisplay.ttf | grep weight
# This outputs 10 weights with fontconfig <= 2.13.93,
# but only 2 weights with fontconfig 2.13.94
```
Use [this script](https://gist.github.com/10eb1a55f1eab6ae0fa77df290b51334) for a fully specified, isolated repro in a [Nix](https://nixos.org/) build.
I've also reproduced this via the `archlinux@sha256:3ac6d1abecb740c95fe990b0cc15cb6d261cb2b18ab2c541119778f5de71d08e` docker image which contains fontconfig `2.13.94`.
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/302
Memory leak in FcPatternObjectAddWithBinding
2023-03-08T14:03:31Z
Ruth Ivimey-Cook
Memory leak in FcPatternObjectAddWithBinding
I believe I have found a memory leak in this function (from 'main' as of 8 Nov 21):
```
FcBool
FcPatternObjectAddWithBinding (FcPattern *p,
FcObject object,
FcValue value,
FcValueBinding binding,
FcBool append)
{
...
I believe I have found a memory leak in this function (from 'main' as of 8 Nov 21):
```
FcBool
FcPatternObjectAddWithBinding (FcPattern *p,
FcObject object,
FcValue value,
FcValueBinding binding,
FcBool append)
{
FcPatternElt *e;
FcValueListPtr new, *prev;
if (FcRefIsConst (&p->ref))
goto bail0;
new = FcValueListCreate ();
if (!new)
goto bail0;
value = FcValueSave (value);
if (value.type == FcTypeVoid)
goto bail1;
/*
* Make sure the stored type is valid for built-in objects
*/
if (!FcObjectValidType (object, value.type))
{
fprintf (stderr,
"Fontconfig warning: FcPattern object %s does not accept value",
FcObjectName (object));
FcValuePrintFile (stderr, value);
fprintf (stderr, "\n");
goto bail1;
}
new->value = value;
new->binding = binding;
new->next = NULL;
e = FcPatternObjectInsertElt (p, object);
if (!e)
goto bail2;
if (append)
{
for (prev = &e->values; *prev; prev = &(*prev)->next)
;
*prev = new;
}
else
{
new->next = e->values;
e->values = new;
}
return FcTrue;
bail2:
FcValueDestroy (value);
bail1:
free (new);
bail0:
return FcFalse;
}
```
There are two things I noted: firstly, FcValueSave can return a value that contains pointers to heap memory (e.g. via strdup). Secondly, that although "free(new)" is adequate to clean up the FcValueListCreate result, as soon as things are written to 'new' the FcValueListDestroy function should be used. Finally once FcValueSave has been called, even if not assigned to 'new', FcValueDestroy must be called on 'value'.
I would suggest changing the code thus:
1. Move "value = FcValueSave(value);" to below the FcObjectValidType() call & 'if' block. As far as I can see, it doesn't need to be any earlier. The reference to 'value.type' in the 'if' block should be the same.
2. Change "free(new);" to "FcValueListDestroy(new);"
3. Now FcValueSave() is beside the "new->value = value;" line, it might as well be directly assigned: "new->value = FcValueSave(value);". Then because of (2), "bail2:" is no longer needed because the FcValueSave() result is either in 'new' or hasn't happened, and if it's in 'new' then FcValueListDestroy() will deal with it.
4. I think there is scope to move the FcPatternObjectInsertElt() call to before new->value initialization, also, though the benefit is lower. Either way, it should "goto bail1" now.
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/301
How does fontconfig handle duplicate font files ?
2021-11-05T11:46:41Z
Abhishek Deshpande
How does fontconfig handle duplicate font files ?
Let's say, I have a font installed in userspace, i.e. in my `~/.local/share/fonts` or `~/.fonts`.
Now, I installed a font package that contains the same font and same version. In this case, both the font files are exact duplicates of eac...
Let's say, I have a font installed in userspace, i.e. in my `~/.local/share/fonts` or `~/.fonts`.
Now, I installed a font package that contains the same font and same version. In this case, both the font files are exact duplicates of each other. Then, which font file will be actually preferred by applications ?
How fontconfig will decide the priority ?
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/299
fc-conflist(1) does not describe the command's output
2021-12-21T11:10:41Z
Ralph Corderoy
fc-conflist(1) does not describe the command's output
The fc-conflist man page does not describe the output of the command.
What it should clarify includes:
- Whether the order of lines is significant.
- What the leading `+` or `-` indicates.
- What the omission of a configuration file ind...
The fc-conflist man page does not describe the output of the command.
What it should clarify includes:
- Whether the order of lines is significant.
- What the leading `+` or `-` indicates.
- What the omission of a configuration file indicates, i.e. all considered configuration files are shown.
Without that, the output is vague and open to multiple interpretations, as has just been proven by multiple parties attempting to independently debug from the same output.
Similarly, the documentation for the functions used, e.g. FcConfigFileInfoIterInit(), doesn't help as that neglects to state if the iterator traverses in a known order.
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/296
add option to not run fc-cache on install for packagers
2021-10-19T04:47:53Z
John Hein
add option to not run fc-cache on install for packagers
When building a package, usually as a regular user, having the install run fc-cache for the system is not desired (and can trigger a 'permission denied' failure).
Patch attached to add an option to allow packagers to disable running fc-...
When building a package, usually as a regular user, having the install run fc-cache for the system is not desired (and can trigger a 'permission denied' failure).
Patch attached to add an option to allow packagers to disable running fc-cache.
[patch-fontconfig-add-fc-cache-opt.txt](/uploads/b48cfc801798db6c824e5fc699cec3e6/patch-fontconfig-add-fc-cache-opt.txt)
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/295
Valgrind show leaks on simple project
2023-09-18T05:24:46Z
D K
Valgrind show leaks on simple project
I tried to build simple example with libXft here https://github.com/jsynacek/xft-example/blob/master/main.c
But got leaks inside libfontconfig (libfontconfig i builded by own hands ver. 2.13.94)
See log below
- ==22809== Memcheck, a ...
I tried to build simple example with libXft here https://github.com/jsynacek/xft-example/blob/master/main.c
But got leaks inside libfontconfig (libfontconfig i builded by own hands ver. 2.13.94)
See log below
- ==22809== Memcheck, a memory error detector
- ==22809== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
- ==22809== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
- ==22809== Command: ./test_xft_fc.out
- ==22809== Parent PID: 4503
- ==22809==
- ==22809==
- ==22809== HEAP SUMMARY:
- ==22809== in use at exit: 448,596 bytes in 7,271 blocks
- ==22809== total heap usage: 18,096 allocs, 10,825 frees, 4,752,662 bytes allocated
- ==22809==
- ==22809== 288 (256 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 191 of 271
- ==22809== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
- ==22809== by 0x4C0993D: FcPatternObjectInsertElt (fcpat.c:545)
- ==22809== by 0x4C0A06F: FcPatternObjectAddWithBinding (fcpat.c:732)
- ==22809== by 0x4C0BB7E: FcPatternAppend (fcpat.c:1281)
- ==22809== by 0x4C1687D: FcParsePattern (fcxml.c:3087)
- ==22809== by 0x4C16B9C: FcEndElement (fcxml.c:3212)
- ==22809== by 0x4F179D9: ??? (in /usr/lib/x86_64-linux-gnu/libexpat.so.1.6.11)
- ==22809== by 0x4F186AF: ??? (in /usr/lib/x86_64-linux-gnu/libexpat.so.1.6.11)
- ==22809== by 0x4F15B82: ??? (in /usr/lib/x86_64-linux-gnu/libexpat.so.1.6.11)
- ==22809== by 0x4F1704D: ??? (in /usr/lib/x86_64-linux-gnu/libexpat.so.1.6.11)
- ==22809== by 0x4F1ADBF: XML_ParseBuffer (in /usr/lib/x86_64-linux-gnu/libexpat.so.1.6.11)
- ==22809== by 0x4C173D8: FcConfigParseAndLoadFromMemoryInternal (fcxml.c:3527)
- ==22809==
- ==22809== 416 (256 direct, 160 indirect) bytes in 1 blocks are definitely lost in loss record 196 of 271
- ==22809== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
- ==22809== by 0x4C0993D: FcPatternObjectInsertElt (fcpat.c:545)
- ==22809== by 0x4C0A06F: FcPatternObjectAddWithBinding (fcpat.c:732)
- ==22809== by 0x4C0A148: FcPatternObjectAdd (fcpat.c:761)
- ==22809== by 0x4C0A4A1: FcPatternObjectAddDouble (fcpat.c:856)
- ==22809== by 0x4C0A4E1: FcPatternAddDouble (fcpat.c:863)
- ==22809== by 0x49A72B2: ??? (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.3)
- ==22809== by 0x49A75BC: ??? (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.3)
- ==22809== by 0x49A788E: ??? (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.3)
- ==22809== by 0x49A7CF1: XftDefaultHasRender (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.3)
- ==22809== by 0x49A812F: XftDefaultSubstitute (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.3)
- ==22809== by 0x49AACBD: XftFontMatch (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.3)
- ==22809==
- ==22809== 2,520 (768 direct, 1,752 indirect) bytes in 1 blocks are definitely lost in loss record 232 of 271
- ==22809== at 0x483DFAF: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
- ==22809== by 0x4C098DB: FcPatternObjectInsertElt (fcpat.c:536)
- ==22809== by 0x4C09EB3: FcPatternObjectListAdd (fcpat.c:670)
- ==22809== by 0x4C05286: FcFontRenderPrepare (fcmatch.c:822)
- ==22809== by 0x4C05BA9: FcFontMatch (fcmatch.c:1025)
- ==22809== by 0x49AACD7: XftFontMatch (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.3)
- ==22809== by 0x49AAFEB: XftFontOpenName (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.3)
- ==22809== by 0x1094FE: main (main.cpp:36)
- ==22809==
- ==22809== LEAK SUMMARY:
- ==22809== definitely lost: 1,280 bytes in 3 blocks
- ==22809== indirectly lost: 1,944 bytes in 66 blocks
- ==22809== possibly lost: 0 bytes in 0 blocks
- ==22809== still reachable: 445,372 bytes in 7,202 blocks
- ==22809== suppressed: 0 bytes in 0 blocks
- ==22809== Reachable blocks (those to which a pointer was found) are not shown.
- ==22809== To see them, rerun with: --leak-check=full --show-leak-kinds=all
- ==22809==
- ==22809== For lists of detected and suppressed errors, rerun with: -s
- ==22809== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
it seems this issue https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/77 very similar to my but has no full information.
Full story begins from my big project which i developing and build on my ubuntu 20.04 LTS - but when i started to test my project with valgrind i've got leaks inside libfontconfig. Then i began to exploring this problem and downloaded ver. 2.13.94 in the hope that it has already been fixed there - but i see problem still persists.
I am just began to investigate the code but it seems some of malloc'ed(or realloc'ed) FcPatternElt not freed by FcPatternDestroy
More details of my assumption perhaps i can tell on this week
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/294
FcPatternGetWithBinding() doesn't work as expected?
2021-08-25T04:03:41Z
Michael Catanzaro
FcPatternGetWithBinding() doesn't work as expected?
[FcPatternGetWithBinding() was added back in 2017.](https://bugs.freedesktop.org/show_bug.cgi?id=19375) The original intention of this API was to allow Skia and WebKit to replace a bunch of [seriously gnarly code](https://bugs.webkit.org...
[FcPatternGetWithBinding() was added back in 2017.](https://bugs.freedesktop.org/show_bug.cgi?id=19375) The original intention of this API was to allow Skia and WebKit to replace a bunch of [seriously gnarly code](https://bugs.webkit.org/show_bug.cgi?id=228927) designed to guess whether a strong or weak alias was followed during font matching. According to the Fontconfig documentation, the difference between strong and weak is that strong matches family before language while weak matches after language:
> The canonical font pattern is finally matched against all available fonts. The distance from the pattern to the font is measured for each of several properties: foundry, charset, family, lang, spacing, pixelsize, style, slant, weight, antialias, rasterizer and outline. This list is in priority order -- results of comparing earlier elements of this list weigh more heavily than later elements.
>
> There is one special case to this rule; family names are split into two bindings; strong and weak. Strong family names are given greater precedence in the match than lang elements while weak family names are given lower precedence than lang elements. This permits the document language to drive font selection when any document specified font is unavailable.
So Skia and WebKit are probably abusing this distinction, but in practice this strategy has worked pretty well to allow us to do *some* font matching while still mostly respecting the ordering of fonts in a `font-family` directive. [More rationale for this here.](https://bugs.webkit.org/show_bug.cgi?id=147057)
Anyway, FcPatternGetWithBinding() was added specifically for use by WebKit and Skia, but neither of us actually ever got around to ever trying to use it, until yesterday. Oops. I tried it and found that every match is reported as using a strong binding, which isn't useful. I asked Akira about this:
> Hmm, apparently there are some tasks we need to fix in fontconfig.
> There was some logic that needed to be changed when it was added. so
> I'm sorry but it won't return FcValueBindingStrong for an
> exact-matched family name and FcValueBindingWeak for others so far.
>
> Also, there is no strict meaning for binding in the returned FcPattern
> more than the precedence on matching. If we are going to change
> fontconfig like what WebKit does, we may need to change it much more.
> Please open an issue for that. Let's keep track of the progress there.
I'm not sure whether this actually makes sense or not, though, since what WebKit and Skia are doing is maybe too different from how the bindings work? Maybe a different API would make more sense instead? Even if the binding was not always reported as strong, it isn't clear what WebKit or Skia should do if the function were to return Same, for example. Our logic assumes the only two options are Strong and Weak.
I ran a Debian codesearch, which indicates that no open source projects are currently using FcPatternGetWithBinding().
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/293
fontconfig ignores generic family system-ui rules
2024-03-25T10:14:12Z
Munzir Taha
fontconfig ignores generic family system-ui rules
In Arch Linux for a new user without any user customizations
```bash
$ fc-match system-ui
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
```
This is strange since `/etc/fonts/conf.d/45-latin.conf` and `/etc/fonts/conf.d/60-latin.conf`...
In Arch Linux for a new user without any user customizations
```bash
$ fc-match system-ui
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
```
This is strange since `/etc/fonts/conf.d/45-latin.conf` and `/etc/fonts/conf.d/60-latin.conf` set it to `Cantarell` which is already available. There is no rule whatsoever by default to set `"Nimbus Sans"` as a `system-ui` font.
It seems `fontconfig` just ignores `system-ui` as can be verified by
`diff <(fc-match -s sans-serif) <(fc-match -s system-ui)`
So, it just fallback to sans and inherited its rules.
Attached is the output of `FC_DEBUG=4 fc-match system-ui` [FC_DEBUG4-fc-match-system-ui](/uploads/ddfe76805647420db32f47cb60dd9c42/FC_DEBUG4-fc-match-system-ui)
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/290
<dir prefix="relative"> does not resolve symlinks
2021-10-11T13:17:15Z
Kyuuhachi
<dir prefix="relative"> does not resolve symlinks
If a path included via `<include>` is a symlink, and the config file pointed to contains a `<dir prefix="relative">` tag, then that path is resolved as relative to the symlink rather than its target.
For example, I have `~/.config/fontc...
If a path included via `<include>` is a symlink, and the config file pointed to contains a `<dir prefix="relative">` tag, then that path is resolved as relative to the symlink rather than its target.
For example, I have `~/.config/fontconfig/fonts.conf` as a symlink to `~/dotfiles/fonts.conf`, which contains `<dir prefix="relative">fonts</dir>`. Naturally, I would expect this to resolve to `~/dotfiles/fonts`. However, as revealed by `FC_DEBUG=8`, it instead looks for `~/.config/fontconfig/fonts`, which does not exist.
Akira TAGOH
Akira TAGOH
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/287
sed: 1: "s,@FC_DEFAULT_FONTS\@,\ ...": bad flag in substitute command: '/'
2021-10-05T09:01:17Z
Ryan Carsten Schmidt
sed: 1: "s,@FC_DEFAULT_FONTS\@,\ ...": bad flag in substitute command: '/'
On macOS 10.13.6 I used fontconfig 2.13.94 and ran:
```
LIBTOOLIZE=glibtoolize ./autogen.sh --prefix=/opt/fontconfig --with-add-fonts=/Library/Fonts,/System/Library/Fonts
make -j$(sysctl -n hw.activecpu)
sudo make install
```
The resul...
On macOS 10.13.6 I used fontconfig 2.13.94 and ran:
```
LIBTOOLIZE=glibtoolize ./autogen.sh --prefix=/opt/fontconfig --with-add-fonts=/Library/Fonts,/System/Library/Fonts
make -j$(sysctl -n hw.activecpu)
sudo make install
```
The result was:
```
sed \
-e 's,@FC_CACHEDIR\@,/opt/fontconfig/var/cache/fontconfig,g' \
-e 's,@FC_DEFAULT_FONTS\@,\t<dir>/System/Library/Fonts,/Library/Fonts,~/Library/Fonts,/System/Library/Assets/com_apple_MobileAsset_Font3,/System/Library/Assets/com_apple_MobileAsset_Font4</dir>\n,g' \
-e 's,@FC_FONTPATH\@,<dir>/Library/Fonts</dir> <dir>/System/Library/Fonts</dir>,g' \
-e 's,@CONFIGDIR\@,conf.d,g' \
-e 's,@PACKAGE\@,fontconfig,g' \
-e 's,@VERSION\@,2.13.94,g' \
./fonts.conf.in > fonts.conf.tmp && \
mv fonts.conf.tmp fonts.conf
sed: 1: "s,@FC_DEFAULT_FONTS\@,\ ...": bad flag in substitute command: '/'
make[2]: *** [fonts.conf] Error 1
make[1]: *** [install-am] Error 2
make: *** [install-recursive] Error 1
```
I noticed that the commas I specified in `--with-add-fonts` have been translated into `</dir> <dir>` within `FC_FONTPATH` but a similar substitution has not been performed in `FC_DEFAULT_FONTS` so the commas within `FC_DEFAULT_FONTS` are interfering with the commas used as separators for sed.
This is caused by a simple mistake in configure.ac:
```diff
diff --git a/configure.ac b/configure.ac
index 7c1a697..93ccf1b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -499,7 +499,7 @@ FC_DEFAULT_FONTS=""
if test x${default_fonts+set} = xset; then
fc_IFS=$IFS
IFS=","
- for p in "$default_fonts"; do
+ for p in $default_fonts; do
FC_DEFAULT_FONTS="$FC_DEFAULT_FONTS\t<dir>$p</dir>\n"
done
IFS=$fc_IFS
```
Once this is fixed, we see that the resulting presentation of this data in fonts.conf is wrong:
```
<!-- Font directory list -->
t<dir>/System/Library/Fonts</dir>nt<dir>/Library/Fonts</dir>nt<dir>~/Library/Fonts</dir>nt<dir>/System/Library/Assets/com_apple_MobileAsset_Font3</dir>nt<dir>/System/Library/Assets/com_apple_MobileAsset_Font4</dir>n
<dir>/Library/Fonts</dir> <dir>/System/Library/Fonts</dir>
<dir prefix="xdg">fonts</dir>
<!-- the following element will be removed in the future -->
<dir>~/.fonts</dir>
```
`\t` and `\n` have been converted to `t` and `n`. (Presumably the code was tested using GNU sed, which replaces `\t` with a tab and `\n` with a newline, but macOS ships with BSD sed which does not have that feature.) I am not certain of the best way to fix this. As far as I know, autoconf config values cannot contain real newlines, so perhaps it is acceptable to forgo the newlines and put everything on one line for `FC_DEFAULT_FONTS` to match how it already is for `FC_FONTPATH`.
I will submit a merge request to fix these issues shortly. Whether using my merge request or another method, please fix these problems before releasing fontconfig 2.14.0 so as to avoid breaking things for macOS users.
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/286
fc-match matching italic style even though regular or bold is specified
2021-07-08T05:59:09Z
Nilas Tim Schüsler
fc-match matching italic style even though regular or bold is specified
Hi, I am experiencing a problem with the newest version of fonconfig (2.13.94) where fc-match matches the italic style of the font [otb-uw_ttyp0](https://aur.archlinux.org/packages/otb-uw_ttyp0/) even though it has been specified that th...
Hi, I am experiencing a problem with the newest version of fonconfig (2.13.94) where fc-match matches the italic style of the font [otb-uw_ttyp0](https://aur.archlinux.org/packages/otb-uw_ttyp0/) even though it has been specified that the style should be regular or bold. This only happens for the font sizes where the font has an italic version. That is the font comes in the following sizes: 6x11, 6x12, 7x13, 7x14, 8x15, 8x16, 9x17, 9x18 and 11x22. The italic version of the font exists in the following sizes: 8x15, 8x16, 9x17 and 9x18. There is only a problem for the sizes 8x15, 8x16, 9x17 and 9x18.
There is e.g. no problem if I use the following commands, then I get the expected outputs:
|command|output|
|---|---|
|`fc-match "UW Ttyp0:style=Regular:pixelsize=14"`|`UW-Ttyp0.otb: "UW Ttyp0" "Regular"`|
|`fc-match "UW Ttyp0:style=Bold:pixelsize=14"`|`UW-Ttyp0-Bold.otb: "UW Ttyp0" "Bold"`|
But for the following commands it matches the italic style:
|command|output|
|---|---|
|`fc-match "UW Ttyp0:style=Regular:pixelsize=16"`|`UW-Ttyp0-Italic.otb: "UW Ttyp0" "Italic"`|
|`fc-match "UW Ttyp0:style=Bold:pixelsize=16"`|`UW-Ttyp0-Italic.otb: "UW Ttyp0" "Italic"`|
I did not experience this issue before version 2.13.94 and the problem goes away when I downgrade to version 2.13.93.
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/283
fc-match does not select regular optical size
2021-06-28T09:25:44Z
Ruud van Asseldonk
fc-match does not select regular optical size
I have a font that comes in multiple optical sizes. These are specified as a suffix of the style, and they are called “Regular”, “Caption”, “Subhead”, and “Display”.
Here is what `fc-scan` reports for the “Regular” optical size:
```
Pa...
I have a font that comes in multiple optical sizes. These are specified as a suffix of the style, and they are called “Regular”, “Caption”, “Subhead”, and “Display”.
Here is what `fc-scan` reports for the “Regular” optical size:
```
Pattern has 26 elts (size 32)
family: "Warnock Pro"(s)
familylang: "en"(s)
style: "Regular"(s)
stylelang: "en"(s)
fullname: "Warnock Pro"(s)
fullnamelang: "en"(s)
slant: 0(i)(s)
weight: 80(f)(s)
width: 100(f)(s)
foundry: "ADBE"(s)
file: "/usr/share/fonts/Warnock Pro/WarnockPro-Regular.otf"(s)
index: 0(i)(s)
outline: True(s)
scalable: True(s)
charset:
0000: 00000000 ffffffff ffffffff 7fffffff 00000000 ffffffff ffffffff ffffffff
0001: ffffffff ffffffff ffffffff ffffffff 00040000 00000000 00001ff0 f00e0000
0002: 0f000000 00800000 02000000 00000000 00000000 00000000 3f0002c0 00000000
0003: 00000000 00000000 00000000 40000000 ffffd7f0 fffffffb 00037fff 00010000
0004: ffffdffe ffffffff dffeffff 003c000c 00030000 00000000 02000000 00000000
001e: 00000000 00000000 00000000 00000000 0000003f 00000000 00000000 000c0000
0020: 771d0000 06010077 00000010 e3f10000 000063ff 0000109a 00000000 00000000
0021: 00480000 00004044 78180000 00000000 00000000 00000000 00000000 00000000
0022: 46268044 00000800 00000100 00000031 00000000 00000000 00000000 00000000
0025: 00000000 00000000 00000000 00000000 00000000 00000000 00000400 00000000
00e0: ffffffff ffffffff ffffffff ffffffff 1fffffff 00000000 00000000 00000000
00ef: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00ae6000
00f6: 00000000 ffbfff00 ffffdfff ffffffff ffffffff 3fffffff b1fffe08 fffefdff
00f7: 00000000 83ff0042 00000000 07ffffff 00000000 81108102 00000000 ff7fffff
00fb: 0000001f 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(s)
lang: aa|af|av|ay|be|bg|bi|br|bs|ca|ce|ch|co|cs|cy|da|de|el|en|eo|es|et|eu|fi|fj|fo|fr|fur|fy|gd|gl|gv|ho|hr|hu|ia|id|ie|ik|io|is|it|ki|kl|kum|la|lb|lez|lt|lv|mg|mh|mo|mt|nb|nds|nl|nn|no|nr|nso|ny|oc|om|os|pl|pt|rm|ro|ru|se|sel|sk|sl|sma|smj|smn|so|sq|sr|ss|st|sv|sw|tk|tl|tn|tr|ts|uk|uz|vo|vot|wa|wen|wo|xh|yap|zu|an|crh|csb|fil|hsb|ht|jv|kj|ku-tr|kwm|lg|li|ms|na|ng|pap-an|pap-aw|rn|rw|sc|sg|sn|su|za(s)
fontversion: 133365(i)(s)
capability: "otlayout:DFLT otlayout:cyrl otlayout:grek otlayout:latn"(s)
fontformat: "CFF"(s)
decorative: False(s)
postscriptname: "WarnockPro-Regular"(s)
color: False(s)
symbol: False(s)
variable: False(s)
fonthashint: False(s)
order: 0(i)(s)
```
And here is what `fc-scan` reports for the “Caption” optical size:
```
Pattern has 26 elts (size 32)
family: "Warnock Pro"(s) "Warnock Pro Caption"(s)
familylang: "en"(s) "en"(s)
style: "Caption"(s) "Regular"(s)
stylelang: "en"(s) "en"(s)
fullname: "Warnock Pro Caption"(s)
fullnamelang: "en"(s)
slant: 0(i)(s)
weight: 80(f)(s)
width: 100(f)(s)
foundry: "ADBE"(s)
file: "/usr/share/fonts/Warnock Pro/WarnockPro-Capt.otf"(s)
index: 0(i)(s)
outline: True(s)
scalable: True(s)
charset:
0000: 00000000 ffffffff ffffffff 7fffffff 00000000 ffffffff ffffffff ffffffff
0001: ffffffff ffffffff ffffffff ffffffff 00040000 00000000 00001ff0 f00e0000
0002: 0f000000 00800000 02000000 00000000 00000000 00000000 3f0002c0 00000000
0003: 00000000 00000000 00000000 40000000 ffffd7f0 fffffffb 00037fff 00010000
0004: ffffdffe ffffffff dffeffff 003c000c 00030000 00000000 02000000 00000000
001e: 00000000 00000000 00000000 00000000 0000003f 00000000 00000000 000c0000
0020: 771d0000 06010077 00000010 e3f10000 000063ff 0000109a 00000000 00000000
0021: 00480000 00004044 78180000 00000000 00000000 00000000 00000000 00000000
0022: 46268044 00000800 00000100 00000031 00000000 00000000 00000000 00000000
0025: 00000000 00000000 00000000 00000000 00000000 00000000 00000400 00000000
00e0: ffffffff ffffffff ffffffff ffffffff 1fffffff 00000000 00000000 00000000
00ef: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00ae6000
00f6: 00000000 ffbfff00 ffffdfff ffffffff ffffffff 3fffffff b1fffe08 fffefdff
00f7: 00000000 83ff0042 00000000 07ffffff 00000000 81108102 00000000 ff7fffff
00fb: 0000001f 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(s)
lang: aa|af|av|ay|be|bg|bi|br|bs|ca|ce|ch|co|cs|cy|da|de|el|en|eo|es|et|eu|fi|fj|fo|fr|fur|fy|gd|gl|gv|ho|hr|hu|ia|id|ie|ik|io|is|it|ki|kl|kum|la|lb|lez|lt|lv|mg|mh|mo|mt|nb|nds|nl|nn|no|nr|nso|ny|oc|om|os|pl|pt|rm|ro|ru|se|sel|sk|sl|sma|smj|smn|so|sq|sr|ss|st|sv|sw|tk|tl|tn|tr|ts|uk|uz|vo|vot|wa|wen|wo|xh|yap|zu|an|crh|csb|fil|hsb|ht|jv|kj|ku-tr|kwm|lg|li|ms|na|ng|pap-an|pap-aw|rn|rw|sc|sg|sn|su|za(s)
fontversion: 133365(i)(s)
capability: "otlayout:DFLT otlayout:cyrl otlayout:grek otlayout:latn"(s)
fontformat: "CFF"(s)
decorative: False(s)
postscriptname: "WarnockPro-Capt"(s)
color: False(s)
symbol: False(s)
variable: False(s)
fonthashint: False(s)
order: 0(i)(s)
```
Now whichever query I write, I have not succeeded in writing a query that matches the first font file by style or name:
```
$ fc-match 'Warnock Pro:style=Regular'
WarnockPro-Capt.otf: "Warnock Pro" "Caption"
$ fc-match 'Warnock Pro:fullname=Warnock Pro Regular'
WarnockPro-Capt.otf: "Warnock Pro" "Caption"
$ fc-match 'Warnock Pro:fullname=Warnock Pro'
WarnockPro-Capt.otf: "Warnock Pro" "Caption"
$ fc-match 'Warnock Pro:style='
WarnockPro-Capt.otf: "Warnock Pro" "Caption"
$ fc-match 'Warnock Pro'
WarnockPro-Capt.otf: "Warnock Pro" "Caption"
```
Selecting by `postscriptname` is so far the only thing that enabled me to select the right font, but this is unsuitable for me, because I’m building an application that selects font by name and style.
```
$ fc-match 'Warnock Pro:postscriptname=WarnockPro-Regular'
WarnockPro-Regular.otf: "Warnock Pro" "Regular"
```
It looks like “Regular” popping up in the -Capt file might be a problem? When I view the file in `gnome-font-viewer`, it just says “Style: Caption”, there is no mention of “Regular”. According to `otfinfo`, the difference is in the “Preferred subfamily” field, which `otfinfo` does not print for -Regular file, but it does for the -Capt file:
```
$ otfinfo --info '/usr/share/fonts/Warnock Pro/WarnockPro-Regular.otf'
Family: Warnock Pro
Subfamily: Regular
Full name: WarnockPro-Regular
PostScript name: WarnockPro-Regular
Version: Version 2.035;PS 2.000;hotconv 1.0.51;makeotf.lib2.0.18671
Unique ID: 2.035;ADBE;WarnockPro-Regular
Designer: Robert Slimbach
Vendor URL: http://www.adobe.com/type
Trademark: Warnock is either a registered trademark or a trademark of Adobe Systems Incorporated in the United States and/or other countries.
Copyright: © 2000 Adobe Systems Incorporated. All rights reserved. Protected by U.S. Patents D454,152.
License URL: http://www.adobe.com/type/legal.html
Vendor ID: ADBE
$ otfinfo --info '/usr/share/fonts/Warnock Pro/WarnockPro-Capt.otf'
Family: Warnock Pro Caption
Subfamily: Regular
Full name: WarnockPro-Capt
PostScript name: WarnockPro-Capt
Preferred family: Warnock Pro
Preferred subfamily: Caption
Version: Version 2.035;PS 2.000;hotconv 1.0.51;makeotf.lib2.0.18671
Unique ID: 2.035;ADBE;WarnockPro-Capt
Designer: Robert Slimbach
Vendor URL: http://www.adobe.com/type
Trademark: Warnock is either a registered trademark or a trademark of Adobe Systems Incorporated in the United States and/or other countries.
Copyright: © 2000 Adobe Systems Incorporated. All rights reserved. Protected by U.S. Patents D454,152.
License URL: http://www.adobe.com/type/legal.html
Vendor ID: ADBE
```
Long story short, I think `fc-match 'Warnock Pro:style=Regular'` should match `WarnockPro-Regular.otf`, instead of matching `WarnockPro-Capt.otf`; right now there doesn’t seem to be a way to match the -Regular font by specifying the style, whereas selecting a different optical size with `:style=Display` does work.
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/282
[feature request] Support WASM architecture target by fixing minor code issue...
2021-07-17T19:51:43Z
Vadim Kantorov
[feature request] Support WASM architecture target by fixing minor code issues breaking Emscripten
Currently I successfully build fontconfig for WebAssembly (under Emscripten) for having an in-browser XeTeX compiler (https://github.com/busytex/busytex).
The only patch needed to compile fontconfig is https://github.com/libass/Javascri...
Currently I successfully build fontconfig for WebAssembly (under Emscripten) for having an in-browser XeTeX compiler (https://github.com/busytex/busytex).
The only patch needed to compile fontconfig is https://github.com/libass/JavascriptSubtitlesOctopus/blob/master/build/patches/fontconfig/0003-fix-fcstats-emscripten.patch
Otherwise I get a compilation error:
```
/home/runner/work/busytex/busytex/source/fontconfig/src/fcstat.c:404:6: error: "BUG: No way to figure out with fstatfs()"
# error "BUG: No way to figure out with fstatfs()"
^
1 error generated.
```
The patch is really minor, so after fixing it, maybe an official recipe could be recommended (my building commands are in https://github.com/busytex/busytex/blob/55d88bf/Makefile#L227).
I think WASM architecture target would become more pertinent in future.
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/281
configure script not found in GitHub Releases' tarballs
2021-06-20T05:24:40Z
Vadim Kantorov
configure script not found in GitHub Releases' tarballs
It seems that the release tarballs are different in
https://github.com/freedesktop/fontconfig/releases and in https://www.freedesktop.org/software/fontconfig/release/
Specifically, in https://www.freedesktop.org/software/fontconfig/rel...
It seems that the release tarballs are different in
https://github.com/freedesktop/fontconfig/releases and in https://www.freedesktop.org/software/fontconfig/release/
Specifically, in https://www.freedesktop.org/software/fontconfig/release/fontconfig-2.13.93.tar.gz `configure` exists and in https://github.com/freedesktop/fontconfig/archive/refs/tags/2.13.93.tar.gz it does not
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/277
Synthesis of full name from family + style should be reverted
2021-06-28T08:49:19Z
Philip Race
Synthesis of full name from family + style should be reverted
In evaluating an OpenJK bug here : https://bugs.openjdk.java.net/browse/JDK-8264703
it appears to me that the root cause is that fontconfig has synthesised a font full name
of "DejaVu Sans Book", and this does not match what the name tab...
In evaluating an OpenJK bug here : https://bugs.openjdk.java.net/browse/JDK-8264703
it appears to me that the root cause is that fontconfig has synthesised a font full name
of "DejaVu Sans Book", and this does not match what the name table file 4 (full name) reports.
This causes clients to be mislead into thinking this is not the font they expected.
The original motivation for
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/merge_requests/82/diffs?commit_id=49ee062f8df74cb134224c903a25cc7594da3ceb
seems to be that fonts which include "Regular" in the full name are in error.
But whatever the motivation there is huge ground for causing confusion if fontconfig does not report
the true actual value in the font.
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/276
Missing <dir> element for WINDOWSFONTDIR when buliding with meson
2021-03-03T13:38:01Z
Akira TAGOH
Missing <dir> element for WINDOWSFONTDIR when buliding with meson
As reported to https://gitlab.freedesktop.org/fontconfig/fontconfig/-/merge_requests/173
As reported to https://gitlab.freedesktop.org/fontconfig/fontconfig/-/merge_requests/173
Akira TAGOH
Akira TAGOH
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/275
build fails using meson
2021-03-03T05:00:43Z
shoober420
build fails using meson
When trying to compile using meson, the build will fail during the install section of the compilation. Here is the log.
[fontconfig-minimal-git-2.13.93+27+gdba3287-1-x86_64-package_fontconfig-minimal-git.log](/uploads/a52af6abda40817b9a...
When trying to compile using meson, the build will fail during the install section of the compilation. Here is the log.
[fontconfig-minimal-git-2.13.93+27+gdba3287-1-x86_64-package_fontconfig-minimal-git.log](/uploads/a52af6abda40817b9a6facc44593edab/fontconfig-minimal-git-2.13.93+27+gdba3287-1-x86_64-package_fontconfig-minimal-git.log)
Here is the build log just for reference.
[fontconfig-minimal-git-2.13.93+27+gdba3287-1-x86_64-build.log](/uploads/c4f4eada5353ea2ed5e9e1755fa29022/fontconfig-minimal-git-2.13.93+27+gdba3287-1-x86_64-build.log)
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/274
Wording in some conf.d/ files
2021-06-25T12:50:04Z
Adrian
Wording in some conf.d/ files
The following message can be found in some configuration files and needs fixing:
```
This configuration is available on the major desktop environments.
We shouldn't overwrite it with "assign" unconditionally.
Most clients ma...
The following message can be found in some configuration files and needs fixing:
```
This configuration is available on the major desktop environments.
We shouldn't overwrite it with "assign" unconditionally.
Most clients may picks up the first value only. so using "append"
may simply works to avoid it.
```
I'm not well versed in fontconfig and don't want to skew the intended meaning, hence a GitLab issue rather than a PR.
The 3rd/4th sentences (they should be 1 sentence) give me an ambiguous feeling. Since ```We shouldn't overwrite``` urges caution, it looks like ```may simply works to avoid it``` is supposed to convey _“may prevent it”_, despite being written like something the user _wants_.
The following files contain the message:
```
conf.d/09-autohint-if-no-hinting.conf
conf.d/10-autohint.conf
conf.d/10-hinting-full.conf
conf.d/10-hinting-medium.conf
conf.d/10-hinting-none.conf
conf.d/10-hinting-slight.conf
conf.d/10-no-sub-pixel.conf
conf.d/10-sub-pixel-bgr.conf
conf.d/10-sub-pixel-rgb.conf
conf.d/10-sub-pixel-vbgr.conf
conf.d/10-sub-pixel-vrgb.conf
conf.d/10-unhinted.conf
conf.d/11-lcdfilter-default.conf
conf.d/11-lcdfilter-legacy.conf
conf.d/11-lcdfilter-light.conf
```
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/273
Why is there an internal FcConfig?
2021-01-17T16:23:27Z
Jacko Dirks
Why is there an internal FcConfig?
This discussion was probably held before somewhere, but I cannot seem to find it.
I am reading into this code, and I keep wondering: why is there an internal FcConfig (src/fccfg.c:41, `static FcConfig *_fcConfig;`)?
If I understand c...
This discussion was probably held before somewhere, but I cannot seem to find it.
I am reading into this code, and I keep wondering: why is there an internal FcConfig (src/fccfg.c:41, `static FcConfig *_fcConfig;`)?
If I understand correctly, there are currently two ways to work with a FcConfig. You can either do it explicitly, by doing something like
```
FcConfig* config = FcInitLoadConfigAndFonts();
...
FcBool success = FcConfigSubstitute(config, pat, FcMatchPattern);
```
Or implcitly
```
...
FcBool success = FcConfigSubstitute(NULL, pat, FcMatchPattern);
```
And the NULL will make sure that the internal FcConfig is created. I feel there are two problems with having both an internal and an external state.
First of all, I feel it might be confusing to the user (it was confusing to me). Say, he has its own, custom config and at some point (due to copy-pasting or whatever) accidentally calls a function with `config == NULL`. Now, Fontconfig silently creates its internal state and finishes correctly. All code works like a charm, but the user gets unexpected results, which might be quite hard to debug.
My second feeling is with the complexity. Because the internal state needs to be checked, managed and threadsafe, `fccfg.c` is pretty complex. If the user has to handle the FcConfig*, this complexity would probably reduce.
Removing this internal FcConfig will break compatibility, that I understand. Are there other reasons why keeping the internal one is preferred over removing it?