fontconfig issues
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues
2021-06-28T09:25:44Z
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/280
Whitelisting takes no precedence over blacklisting
2021-06-21T13:10:21Z
Niek van der Maas
Whitelisting takes no precedence over blacklisting
Reading [this documentation](https://wiki.archlinux.org/title/font_configuration#Whitelisting_and_blacklisting_fonts) it appears that whitelisting should take precedence over blacklisting.
In other words, this should work:
```xml
<sel...
Reading [this documentation](https://wiki.archlinux.org/title/font_configuration#Whitelisting_and_blacklisting_fonts) it appears that whitelisting should take precedence over blacklisting.
In other words, this should work:
```xml
<selectfont>
<!-- global blacklist of all fonts -->
<rejectfont>
<glob>/usr/share/fonts/*</glob>
</rejectfont>
<!-- whitelist specific fonts -->
<acceptfont>
<glob>/usr/share/fonts/fontfile.ttf</glob>
</acceptfont>
</selectfont>
```
Unfortunately this doesn't seem to be the case, with a config like above I get no fonts at all. Is there any other way to reject a glob and re-add specific fonts later?
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/279
conf.d: priorities for Liberation and other fonts?
2021-04-23T18:48:11Z
mikhailnov
conf.d: priorities for Liberation and other fonts?
Seems that Liberation fonts (Liberation Sans, Serif, Mono) should be added to conf.d. These are very wide spread fonts.
Not only latin ones.
I have Liberation Mono installed but it is not used as "Monospace", see screenshot:
![image](...
Seems that Liberation fonts (Liberation Sans, Serif, Mono) should be added to conf.d. These are very wide spread fonts.
Not only latin ones.
I have Liberation Mono installed but it is not used as "Monospace", see screenshot:
![image](/uploads/08b4c9064100974dd7f9ab8ef8fe8848/image.png)
(URL from screenshot: https://abf.io/soft/rosa-xfce-config/commit/423ac723d2aa4b0880580bb94678511774d238c7.patch)
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/278
slant may be set to incorrect value if a font is just oblique but italic
2021-04-09T05:21:31Z
GreenYun
slant may be set to incorrect value if a font is just oblique but italic
I was dealing with a font that was designed to be Oblique style and named Regular while the Italic style of the same family is designed to be more slant. Fontconfig set `slant` to `FC_SLANT_ITALIC` when configuring these two font files, ...
I was dealing with a font that was designed to be Oblique style and named Regular while the Italic style of the same family is designed to be more slant. Fontconfig set `slant` to `FC_SLANT_ITALIC` when configuring these two font files, thus, they were treat to be the same finally, and the Regular style font was omitted when I was going to match the font using the family name.
Of course I can write more rules to tell Fontconfig how to choose the font, but I don't think it a good way when dealing a lot of fonts.
Here is some information from the [OpenType Specification](https://docs.microsoft.com/en-us/typography/opentype/spec/os2):
> **Bit 9:**
>
> If bit 9 is set, then this font is to be considered an “oblique” style by processes which make a distinction between oblique and italic styles, such as Cascading Style Sheets font matching. For example, a font created by algorithmically slanting an upright face will set this bit.
>
> If a font has a version 4 or later OS/2 table and this bit is not set, then this font is not to be considered an “oblique” style. For example, a font that has a classic italic design will not set this bit.
>
> This bit, unlike the ITALIC bit (bit 0), is not related to style-linking in applications that assume a four-member font-family model comprised of regular, italic, bold and bold italic. It may be set or unset independently of the ITALIC bit. In most cases, if OBLIQUE is set, then ITALIC will also be set, though this is not required.
And some related codes from [here](https://gitlab.freedesktop.org/fontconfig/fontconfig/-/blob/6f27f42e6140030715075aa3bd3e5cc9e2fdc6f1/src/fcfreetype.c#L1954):
```C
/*
* Pull default values from the FreeType flags if more
* specific values not found above
*/
if (slant == -1)
{
slant = FC_SLANT_ROMAN;
if (face->style_flags & FT_STYLE_FLAG_ITALIC)
slant = FC_SLANT_ITALIC;
}
```
I am looking forward to some new codes that set `slant` to `FC_SLANT_OBLIQUE` as the font is just only oblique, or the font named Regular having oblique bit set. Also, please aware the content from the name table when doing font style detection, not just pulling the flags from FreeType.
There may be some helpful info from [this issue of FreeType](https://gitlab.freedesktop.org/freetype/freetype/-/issues/1044) and [this](https://gitlab.freedesktop.org/freetype/freetype/-/issues/1045) if developers of FreeType share some good idea dealing with oblique fonts.
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?
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/272
Build fails when docbook2html is missing (2.13.93)
2021-03-26T07:03:10Z
Apteryks
Build fails when docbook2html is missing (2.13.93)
Hello!
Building with the following dependencies: `expat@2.2.10 font-dejavu@2.37 freetype@2.10.1 gperf@3.1 pkg-config@0.29.2 python-minimal@3.8.5 util-linux@2.35.2`
```
[...]
Making all in doc
make[2]: Entering directory '/tmp/guix-buil...
Hello!
Building with the following dependencies: `expat@2.2.10 font-dejavu@2.37 freetype@2.10.1 gperf@3.1 pkg-config@0.29.2 python-minimal@3.8.5 util-linux@2.35.2`
```
[...]
Making all in doc
make[2]: Entering directory '/tmp/guix-build-fontconfig-2.13.93.drv-0/fontconfig-2.13.93/doc'
make[2]: *** No rule to make target 'fcatomic.sgml', needed by 'all'. Stop.
make[2]: Leaving directory '/tmp/guix-build-fontconfig-2.13.93.drv-0/fontconfig-2.13.93/doc'
make[1]: *** [Makefile:627: all-recursive] Error 1
make[1]: Leaving directory '/tmp/guix-build-fontconfig-2.13.93.drv-0/fontconfig-2.13.93'
make: *** [Makefile:513: all] Error 2
command "make" "-j" "24" failed with status 2
```
This appears to be caused by the doc SGML files not being generated when docbook2html is missing. I used the .tar.xz release archive for the 2.13.93 release.
Akira TAGOH
Akira TAGOH
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/271
feature request: Add support for XDG_DATA_DIRS
2021-03-30T06:22:09Z
Apteryks
feature request: Add support for XDG_DATA_DIRS
Hello,
The XDG base directory specification (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) defines the XDG_DATA_DIRS as "a set of preference ordered base directories relative to which data files should be...
Hello,
The XDG base directory specification (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) defines the XDG_DATA_DIRS as "a set of preference ordered base directories relative to which data files should be searched".
fontconfig currently only supports the XDG_DATA_HOME XDG environment variable, which is user-specific and can only include a single location.
Honoring XDG_DATA_DIRS would allow for fonts discovery on system where following the File Hierarchy Standard (FHS) is not practical (such as GNU Guix, NixOS, etc.)
Thank you for your consideration!
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/270
Strange behaviour of fontconfig priority for 'Lohit Devanagari'
2020-12-25T04:42:55Z
Ghost User
Strange behaviour of fontconfig priority for 'Lohit Devanagari'
Some days ago, I installed _Lohit Devanagari_ font on my MX 19.3 box. Since then, I am experiencing strange behavior of fontconfig priority. I seen that _Lohit Devanagari_ is set default for Devanagari script, but not all apps obeying th...
Some days ago, I installed _Lohit Devanagari_ font on my MX 19.3 box. Since then, I am experiencing strange behavior of fontconfig priority. I seen that _Lohit Devanagari_ is set default for Devanagari script, but not all apps obeying this rule. Instead of _Lohit Devanagari_, buggy _FreeSans_ font is being preferred, causing broken rendering of Devanagari. This issue is mainly affecting Chromium and Chromium based browsers.
The package _fonts-lohit-deva_ has two config files -
1. `/etc/fonts/conf.avail/59-lohit-devanagari.conf`
2. `/etc/fonts/conf.avail/66-lohit-devanagari.conf`
In these files, the first one is just a family substitution rule. The second one is responsible for setting _Lohit Devanagari_ as default font for Devanagari script. It has the following syntax -
```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<match>
<test name="lang" compare="contains">
<string>hi</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>mr</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>kok</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>ks@devanagari</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>sd@devanagari</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>mai</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>ne</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>brx</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>doi</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>sa</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<match>
<test name="lang" compare="contains">
<string>sat</string>
</test>
<test name="family">
<string>sans-serif</string>
</test>
<edit name="family" mode="prepend">
<string>Lohit Devanagari</string>
</edit>
</match>
<alias>
<family>Lohit Devanagari</family>
<default>
<family>sans-serif</family>
</default>
</alias>
</fontconfig>
```
I couldn't figure out what causing this problem, because, even things are set correctly to use _Lohit_, unifont is preferred over it. I have previously used Ubuntu 20.04.1 & Arch. They have no such issue, and _Lohit_ is correctly preferred. I checked Ubuntu and Arch fontconfig rules for any syntax changes but found that the code I am using is very similar to them...! 🤔
This issue seems to be affecting many Linux distros, because such problems have been discussed earlier on internet, especially for browsers.
Is it a bug ? Is it fixed previously in upstream ?
**Edit -** I have currently solved this problem by creating a local `fonts.conf` file. But, it should not require to do so.
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/269
fonts-conf(5): issues with automatic generation by docbook2man
2021-08-12T06:03:28Z
ratijas
fonts-conf(5): issues with automatic generation by docbook2man
Seems like docbook2man isn't perfect when it comes to XML. Can't blame it for that, since XML is a mess anyway, but it goes.
Subsections in the **CONFIGURATION FILE FORMAT** section are wrong. They get uppercased (although subsections a...
Seems like docbook2man isn't perfect when it comes to XML. Can't blame it for that, since XML is a mess anyway, but it goes.
Subsections in the **CONFIGURATION FILE FORMAT** section are wrong. They get uppercased (although subsections are usually lowercase), and converted to groff without proper quoting.
## Steps to reproduce
1. Open `man 5 fonts-conf`
2. Scroll down.
## Expected output
```xml
<include ignore_missing="no" prefix="default">
```
## Actual output
Rendered man page:
```
<INCLUDE IGNORE_MISSING= NO" PREFIX="DEFAULT">"
```
Groff source:
```txt
.SS "<INCLUDE IGNORE_MISSING=\&"NO\&" PREFIX=\&"DEFAULT\&">"
```
## Solution
The proper way to generate groff source for that is to char-escape double quotes. According to **groff_char**(7), ASCII double quote can be unambiguously represented as `\[dq]`.
```
.SS <include ignore_missing=\&\[dq]no\&\[dq] prefix=\&\[dq]default\&\[dq]>
```
Also, would be better to highlight attribute values with underline style, which in man pages often stands for user input placeholder. That would require breaking up `<literal> in source \*.sgml sources and possibly inventing new elements.
![image](/uploads/cd0394c4b27fd7c6844be50077cc14c5/image.png)
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/268
49-sansserif.conf cause to bug with Google Docs in Firefox
2020-12-19T19:13:50Z
Renat Nasridinov
49-sansserif.conf cause to bug with Google Docs in Firefox
When using Google Docs and Sheets In Firefox browser, "sans serif" and "Courier New" fonts are displayed as serif font (see attached screenshot).
This behavior is absent for the same document opened in Chromium browser.
* fontconfig v...
When using Google Docs and Sheets In Firefox browser, "sans serif" and "Courier New" fonts are displayed as serif font (see attached screenshot).
This behavior is absent for the same document opened in Chromium browser.
* fontconfig version -- 2:2.13.91+48+gfcb0420
* xorg-font-utils version -- 7.6, xorg-font-util -- 1.3.2
* Linux distro -- Arch Linux
* Firefox versions affected -- 83.0 and 84.0b8 developer edition and many prior them
After disabling `49-sansserif.conf` loading via removing symlink, problem disappeared.
![Google Docs in Firefox](/uploads/87b43e0b9cbf561986cfe28cd23661f0/pyTH2Sp.png)
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/267
49-sansserif.conf doesn't work since 13015a0a
2020-12-17T05:12:15Z
Szunti
49-sansserif.conf doesn't work since 13015a0a
`FC_DEBUG=4 build/fc-match/fc-match DejaVu` output:
```
...
Add Rule(kind:0, name: /etc/fonts/conf.d/49-sansserif.conf) [test]
pattern all family NotEqual "sans-serif"
pattern all family NotEqual "serif"
pattern ...
`FC_DEBUG=4 build/fc-match/fc-match DejaVu` output:
```
...
Add Rule(kind:0, name: /etc/fonts/conf.d/49-sansserif.conf) [test]
pattern all family NotEqual "sans-serif"
pattern all family NotEqual "serif"
pattern all family NotEqual "monospace"
[edit]
Edit family AppendLast "sans-serif";
...
Rule Set: /etc/fonts/conf.d/11-lcdfilter-default.conf
Substitute Edit lcdfilter Append lcddefault
Append list before [marker]
Append list after 1(i)(w)
FcConfigSubstitute editPattern has 6 elts (size 16)
family: "DejaVu"(s)
hintstyle: 1(i)(w)
rgba: 1(i)(w)
lang: "hu"(w)
lcdfilter: 1(i)(w)
prgname: "fc-match"(s)
...
Rule Set: /etc/fonts/conf.d/49-sansserif.conf
FcConfigSubstitute test pattern all family NotEqual "sans-serif"
No match
```
Bisecting resulted in 13015a0a as first bad commit.
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/266
Current version of libfreetype6 has a vulnerability
2020-11-25T04:16:46Z
Chuck Kuo
Current version of libfreetype6 has a vulnerability
Would it be possible to update the dependency on libfreetype6 from 2.9.1-3+deb10u1 to 2.9.1-3+deb10u2? A vulnerability related to embedded PNG bitmap handling was revealed and it would be nice to use a secure version.
Would it be possible to update the dependency on libfreetype6 from 2.9.1-3+deb10u1 to 2.9.1-3+deb10u2? A vulnerability related to embedded PNG bitmap handling was revealed and it would be nice to use a secure version.
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/265
Tag 2.13.93 (2.14 RC3)?
2020-12-04T16:04:43Z
Ben Wagner
Tag 2.13.93 (2.14 RC3)?
It appears there are currently 85 changes since 2.13.92 (2.14 RC2) was tagged over a year ago. There have been a number of threading issues, at least one memory leak, and one read out of bounds fixed since that release.
There are a few ...
It appears there are currently 85 changes since 2.13.92 (2.14 RC2) was tagged over a year ago. There have been a number of threading issues, at least one memory leak, and one read out of bounds fixed since that release.
There are a few users I know who would benefit from picking up these changes but are averse to a large patch pile or using an untagged commit. Tagging a 2.13.93 at this point could aid in such users providing more testing of recent changes.
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/264
font substitution
2020-11-04T23:23:28Z
julien tayon
font substitution
I had a bug on orgmode website due to the "width/height" parameter in the CSS, so I thought, it is a CSS bug ?
Then, I talked to the dev, and realize it was not,
then, I found a bug similar to mine in firefox, so I thought it was a bug...
I had a bug on orgmode website due to the "width/height" parameter in the CSS, so I thought, it is a CSS bug ?
Then, I talked to the dev, and realize it was not,
then, I found a bug similar to mine in firefox, so I thought it was a bug in firefox
https://bugzilla.mozilla.org/show_bug.cgi?id=1336049
Then, I decided to try andrei idea and check it.
Well, guess what, apparently there is a bug that appears in mozilla preventing me to see my dyslexic font when none of the fallback given for a font are installed (or so I imagine, because I don't understand the man pages of fc)
Not my nicest bash script but here is the gist of it
first of all no bug when trying to substitute and unknown font prior to the one I want
Hence font MUST be referenced for the bug to appear.
- then trying font substitution in firefox for all fonts declared in fc
- then looking witch one fail by comparing the screenshot from an headless firefox
- look which one are installed
- look which one are supposed to be used for substitution
- then try to see how much of the proposed fonts for substitution are existing on installation
On my OS (reported also on alpine hence the reason I fill the bug here and not on my distro)
I have 0 success for the proposal of subsitution when looking up for the failed fonts
**HOWTO reproduce**
1. create a profile with andika installed https://software.sil.org/andika/
2. open about:config and try to set the substiution proposed
```
user_pref("font.default.x-western", "Andika");
user_pref("font.name-list.serif.x-western","Andika");
```
3. close ALL your firefox
4. run this script
5. expect a "Point proven"
NB https://gist.github.com/jul/ac13585656499ec9b23a27bcc2ffb7bf
EDIT 180 font fails at home / 314 edited a bug on the fly
PPS I hate mardown
```
#!/usr/bin/bash
MIN_FF_OPT=" --headless "
FF="firefox $MIN_FF_OPT"
die() { echo "$@"; exit 0;}
fc-match Andika || die "le test va pas marcher"
echo "basically if I could create profile from scratch I would put only this"
cat <<EOF
user_pref("font.default.x-western", "Andika");
user_pref("font.name-list.serif.x-western","Andika");
EOF
SUCC=0
FAIL=0
RZ='\e[0m'
GR=${GR-'\e[92m'}
RD=${RD-'\e[91m'}
HL=${HL-'\e[1m'}
TOTAL=$( fc-list | cut -d ":" -f 2 | cut -d "," -f 1 | sed -e 's/^ //' | sort | uniq | wc -l )
OK() { SUCC=$(( SUCC + 1 )); echo -n "$@ :"; echo -e "${HL}${GR}OK${RZ} ($SUCC/$TOTAL)"; echo "$@" >> success.txt; }
KO() { FAIL=$(( FAIL + 1 )); echo -n "$@ :"; echo -e "${HL}${RD}KO${RZ} ($SUCC/$TOTAL)"; echo "$@" >> failture.txt; }
echo "what is the name of the profile for the test ?"
read -r PROFILE
FF="firefox -P $PROFILE $MIN_FF_OPT"
# edit
rm success.txt failture.txt
$FF --screenshot ref.png 'data:text/html,<body style="font-family: serif">test'
diff -q ref.png ref2.png && OK serif || KO serif
$FF --screenshot ref2.png "data:text/html,<body style=\"font-family: 'DejaVu Serif', serif\">test"
diff -q ref.png ref2.png && OK Dejavu Serif || KO dejavu serif
while IFS= read -r font
do
$FF --screenshot ref2.png "data:text/html,<body style=\"font-family: '$font', serif\">test" &> /dev/null
diff -q ref.png ref2.png &> /dev/null && OK "$font" || KO "$font"
done <<< "$( fc-list | cut -d ":" -f 2 | cut -d "," -f 1 | sed -e 's/^ //' | sort | uniq ) "
fc-list -b | perl -ane 'm!/([a-zA-Z]+)\-!; print "$1\n";' | sort | uniq > installed_fonts
while IFS= read -r font; do fc-match "$font"; done < failture.txt | cut -d ":" -f 1 > matched_fonts.txt
TOTAL=$( wc -l failture.txt | cut -d " " -f 1 )
SUCC=0
FAIL=0
while IFS= read -r font; do grep "$font" installed_fonts &> /dev/null && OK "$font" || KO "$font" ; done < matched_fonts.txt
[[ $SUCC == "0" ]] && echo -e "${HL}${RD}point proven if a font has no matched installed fonts in fc-match substitution fail${RZ}"
```
![res2](/uploads/820963a2996c9dde2f364ff03e8602fb/res2.png)
![res1](/uploads/020055406b6321fcf8af028d20493164/res1.png)[](url)