fontconfig issueshttps://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues2018-08-21T03:13:12Zhttps://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/96Missing closing bracket in src/fcstr.c (git master)2018-08-21T03:13:12ZBugzilla Migration UserMissing closing bracket in src/fcstr.c (git master)## Submitted by sor..@..teo.jp
Assigned to **fon..@..op.org**
**[Link to original bug (#107444)](https://bugs.freedesktop.org/show_bug.cgi?id=107444)**
## Description
There is a missing closing bracket in src/fcstr.c at line 875: ...## Submitted by sor..@..teo.jp
Assigned to **fon..@..op.org**
**[Link to original bug (#107444)](https://bugs.freedesktop.org/show_bug.cgi?id=107444)**
## Description
There is a missing closing bracket in src/fcstr.c at line 875: https://cgit.freedesktop.org/fontconfig/tree/src/fcstr.c#n875
Patch:
diff --git a/src/fcstr.c b/src/fcstr.c
index bfddd68..4247c85 100644
--- a/src/fcstr.c
+++ b/src/fcstr.c
@@ -872,7 +872,7 @@ FcStrIsAbsoluteFilename (const FcChar8 *s)
{
#ifdef _WIN32
if (*s == '\\' ||
- (isalpha (*s) && s[1] == ':' && (s[2] == '/' || s[2] == '\\'))
+ (isalpha (*s) && s[1] == ':' && (s[2] == '/' || s[2] == '\\')))
return FcTrue;
#endif
return *s == '/';
--
2.18.0https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/27FC_FULLNAME wrong for variable-font instances2022-07-01T06:16:03ZBugzilla Migration UserFC_FULLNAME wrong for variable-font instances## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#107165)](https://bugs.freedesktop.org/show_bug.cgi?id=107165)**
## Description
We don't override it. We should create fullname from family a...## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#107165)](https://bugs.freedesktop.org/show_bug.cgi?id=107165)**
## Description
We don't override it. We should create fullname from family and style. It's hard to do it right with regard to different languages...
For varfonts, currently fullname gets set to the fullname of the default style. We should probably just copy family to fullname for varfonts.https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/40run-test271.sh failing2019-08-07T07:35:59ZBugzilla Migration Userrun-test271.sh failing## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#102025)](https://bugs.freedesktop.org/show_bug.cgi?id=102025)**
## Description
I'm getting out:
Fixed:pixelsize=16
Fixed:pixelsize=6
=
Fixed...## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#102025)](https://bugs.freedesktop.org/show_bug.cgi?id=102025)**
## Description
I'm getting out:
Fixed:pixelsize=16
Fixed:pixelsize=6
=
Fixed:pixelsize=16
Fixed:pixelsize=6
=
Fixed:pixelsize=16
Fixed:pixelsize=6
whereas expected is:
Misc Fixed:pixelsize=6
Sony Fixed:pixelsize=16
=
Misc Fixed:pixelsize=6
Sony Fixed:pixelsize=16
=
Misc Fixed:pixelsize=6
Sony Fixed:pixelsize=16https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/89Consider moving fontconfig-monitor into fontconfig tree2018-10-02T07:28:29ZBugzilla Migration UserConsider moving fontconfig-monitor into fontconfig tree## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#101997)](https://bugs.freedesktop.org/show_bug.cgi?id=101997)**
## Description
The code at:
https://github.com/behdad/fontconfig-monitor## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#101997)](https://bugs.freedesktop.org/show_bug.cgi?id=101997)**
## Description
The code at:
https://github.com/behdad/fontconfig-monitorhttps://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/60Make fontconfig cache relocatable2020-02-28T04:45:41ZBugzilla Migration UserMake fontconfig cache relocatable## Submitted by Akira TAGOH `@tagoh`
Assigned to **Akira TAGOH `@tagoh`**
**[Link to original bug (#101889)](https://bugs.freedesktop.org/show_bug.cgi?id=101889)**
## Description
Current fontconfig caches are supposed to be matche...## Submitted by Akira TAGOH `@tagoh`
Assigned to **Akira TAGOH `@tagoh`**
**[Link to original bug (#101889)](https://bugs.freedesktop.org/show_bug.cgi?id=101889)**
## Description
Current fontconfig caches are supposed to be matched one-by-one to fonts. when fonts has been moved somewhere or doing bind-mounts fonts directories somewhere else would causes rebuilding caches and can't share it on them (which is the main target this time).
This also affects the startup time for applications and caches should supports relocation without rebuilding.https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/58fontconfig cache creation takes a long time during GIMP startup2018-10-02T06:09:00ZBugzilla Migration Userfontconfig cache creation takes a long time during GIMP startup## Submitted by Michael Schumacher
Assigned to **fon..@..op.org**
**[Link to original bug (#101820)](https://bugs.freedesktop.org/show_bug.cgi?id=101820)**
## Description
On Microsoft Windows platforms, the first start of an appli...## Submitted by Michael Schumacher
Assigned to **fon..@..op.org**
**[Link to original bug (#101820)](https://bugs.freedesktop.org/show_bug.cgi?id=101820)**
## Description
On Microsoft Windows platforms, the first start of an application using fontconfig can be the first time the fontconfig cache is actually created.
For GIMP, we get the occasionally bug report that this takes a very long time on startup, on every DST change (due to how MS Windows reports file modification dates), and sometimes "every time".
We take that last one with several grains of salt, because "every time" may just be "I noticed it the last time I started GIMP, and oops it doesn't happen just now...".
Anyway, in bug https://bugzilla.gnome.org/show_bug.cgi?id=782676 there is a description of what is happening to some users upgrading to GIMP 2.8.22 right now - including a copy of the fontconfig cache folder which allows to reproduce the issue.
Maybe someone working on fontconfig can shed some light on the issue, and tells us whether this is an issue in fontconfig, or in the way it is packaged in the GIMP installers, or the way it is used by GIMP?
### See also
* [Bug 782676](https://bugzilla.gnome.org/show_bug.cgi?id=782676)
* https://bugs.freedesktop.org/show_bug.cgi?id=99360https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/10Build failure with 2.12.32022-07-01T06:16:02ZBugzilla Migration UserBuild failure with 2.12.3## Submitted by Christoph Reiter
Assigned to **Akira TAGOH `@tagoh`**
**[Link to original bug (#101280)](https://bugs.freedesktop.org/show_bug.cgi?id=101280)**
## Description
CC fcobjs.lo
In file included from ../../fontconf...## Submitted by Christoph Reiter
Assigned to **Akira TAGOH `@tagoh`**
**[Link to original bug (#101280)](https://bugs.freedesktop.org/show_bug.cgi?id=101280)**
## Description
CC fcobjs.lo
In file included from ../../fontconfig-2.12.3/src/fcobjs.c:33:0:
fcobjshash.gperf:28:1: error: conflicting types for 'FcObjectTypeHash'
../../fontconfig-2.12.3/src/fcobjs.c:28:1: note: previous declaration of 'FcObjectTypeHash' was here
FcObjectTypeHash (register const char *str, register FC_GPERF_SIZE_T len);
^~~~~~~~~~~~~~~~
In file included from ../../fontconfig-2.12.3/src/fcobjs.c:33:0:
fcobjshash.gperf:172:1: error: conflicting types for 'FcObjectTypeLookup'
../../fontconfig-2.12.3/src/fcobjs.c:31:1: note: previous declaration of 'FcObjectTypeLookup' was here
FcObjectTypeLookup (register const char *str, register FC_GPERF_SIZE_T len);
^~~~~~~~~~~~~~~~~~
Building on 64bit mingw (msys2)
2.12.1 Builds fine
gperf version is 3.1
FC_GPERF_SIZE_T in config.h is size_thttps://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/45X11 fc-cache and XQuartz fc-cache disagree, causing 100% CPU at every start o...2018-10-02T06:36:46ZBugzilla Migration UserX11 fc-cache and XQuartz fc-cache disagree, causing 100% CPU at every start of XQuartz## Submitted by Jörg Höhle
Assigned to **fon..@..op.org**
**[Link to original bug (#100278)](https://bugs.freedesktop.org/show_bug.cgi?id=100278)**
## Description
Hi,
I recently installed XQuartz 2.7.11 (incl. fontconfig 2.12) on...## Submitted by Jörg Höhle
Assigned to **fon..@..op.org**
**[Link to original bug (#100278)](https://bugs.freedesktop.org/show_bug.cgi?id=100278)**
## Description
Hi,
I recently installed XQuartz 2.7.11 (incl. fontconfig 2.12) on my OSX 10.6.8 64 bit Mac Mini machine, upgrading from Apple's X11 (2.3.6). When XQuartz starts, the CPU gets 100% busy for one minute, while two instances of fc-cache produce error messages. One instance is reported as org.macosforge.xquartz.privileged_startx, the other is org.macosforge.xquartz.startx in Konsole.app.
What seems to distinguish my bug report from other ones about fc-cache is that X11 fc-cache and XQuartz disagree. X11 fc-cache finds everything is fine, while XQuartz fc-cache wants to recache *every* directory and fails at that, each time XQuartz starts.
Otherwise, it seems very similar to the old https://github.com/XQuartz/xquartz-old-tickets/blob/master/ticket/820.md about 2.7.5.
So the issue is:
A) Either disagreement is normal, e.g. because the file format changed; (But then, how can X11 still run after installing XQuartz?)
In that case, the present issue is about a bug in the XQuartz installer process, which should have generated proper caches initially.
B) Or XQuartz fc-cache is wrong, for whatever reason; the caches are fine and fc-cache should be quiet and exit fast.
I don't believe that the installation process failed. "ls -alt" shows that some root-owned files named fonts.* were created when I installed XQuartz last week:
$ LANG=C ls -alt /opt/X11/share/fonts/misc
-rw-r--r-- 1 root wheel 32637 Mar 12 20:50 fonts.dir
drwxr-xr-x 416 root wheel 14144 Mar 12 20:49 .
-rw-r--r-- 1 root wheel 4268 Mar 12 20:49 encodings.dir
-rw-r--r-- 1 root wheel 2 Mar 12 20:49 fonts.scale
-rw-r--r-- 1 root wheel 19562 Mar 12 20:49 fonts.list
-rw-r--r-- 1 root wheel 6270 Oct 7 19:23 fonts.alias
-rw-r--r-- 1 root wheel 1371 Oct 7 19:23 olcursor.pcf.gz
[...]
Note that in /usr/X11R6/lib/X11/fonts/ no files were updated, except in encodings/
$ ls -alt /usr/X11R6/lib/X11/fonts/misc
-rw-r--r-- 1 root wheel 32637 Feb 2 2013 fonts.dir
drwxr-xr-x 416 root wheel 14144 Feb 2 2013 .
-rw-r--r-- 1 root wheel 4456 Feb 2 2013 encodings.dir
-rw-r--r-- 1 root wheel 2 Feb 2 2013 fonts.scale
[...]
$ ls -alt /usr/X11R6/lib/X11/fonts/encodings
drwxr-xr-x 38 root wheel 1292 Mar 19 09:07 .
-rw-r--r-- 1 root wheel 4456 Mar 19 09:07 encodings.dir
drwxr-xr-x 12 root wheel 408 May 19 2009 ..
-rw-r--r-- 1 root wheel 616 May 19 2009 microsoft-cp1250.enc.gz
[...]
Is that how the files should be?
What I don't understand is why xquartz.privileged_startx equally fails to write caches, as it seems to run as root, whereas xquartz.startx runs under the normal login UID, according to the Activity Monitor.app.
Here is X11's fc-cache -v output (edited for brevity):
/usr/X11/lib/X11/fonts: skipping, existing cache is valid: 0 fonts, 10 dirs
/usr/X11/..fonts/100dpi: skipping, existing cache is valid: 398 fonts, 0 dirs
[...]
/usr/X11/..fonts/encodings: skipping, existing cache is valid: 0 fonts, 1 dirs
/usr/X11/..fonts/encodings/large: skipping, existing cache is valid: 0 fonts, 0 dirs
/usr/X11/..fonts/misc: skipping, existing cache is valid: 59 fonts, 0 dirs
/usr/X11/..fonts/util: skipping, existing cache is valid: 0 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts: skipping, existing cache is valid: 0 fonts, 10 dirs
/usr/X11R6/..fonts/100dpi: skipping, existing cache is valid: 398 fonts, 0 dirs
[...]
/usr/X11R6/..fonts/encodings: skipping, existing cache is valid: 0 fonts, 1 dirs
/usr/X11R6/..fonts/encodings/large: skipping, existing cache is valid: 0 fonts, 0 dirs
/usr/X11R6/..fonts/misc: skipping, existing cache is valid: 59 fonts, 0 dirs
/usr/X11R6/..fonts/util: skipping, existing cache is valid: 0 fonts, 0 dirs
/Users/foobar/.fonts: skipping, no such directory
/System/Library/Fonts: skipping, existing cache is valid: 69 fonts, 0 dirs
/Library/Fonts: skipping, existing cache is valid: 211 fonts, 0 dirs
/Users/foobar/Library/Fonts: skipping, existing cache is valid: 0 fonts, 0 dirs
/usr/X11/var/cache/fontconfig: not cleaning unwritable cache directory
/Users/foobar/.fontconfig: cleaning cache directory
fc-cache: succeeded
For comparison, XQuartz output:
$ time fc-cache -v
/opt/X11/share/fonts: caching, new cache contents: 0 fonts, 10 dirs
/opt/X11/share/fonts: failed to write cache
/opt/X11/share/fonts/100dpi: caching, new cache contents: 398 fonts, 0 dirs
/opt/X11/share/fonts/100dpi: failed to write cache
[...]
/opt/X11/share/fonts/encodings: caching, new cache contents: 0 fonts, 1 dirs
/opt/X11/share/fonts/encodings: failed to write cache
/opt/X11/share/fonts/encodings/large: caching, new cache contents: 0 fonts, 0 dirs
/opt/X11/share/fonts/encodings/large: failed to write cache
/opt/X11/share/fonts/misc: caching, new cache contents: 59 fonts, 0 dirs
/opt/X11/share/fonts/misc: failed to write cache
/opt/X11/share/fonts/util: caching, new cache contents: 0 fonts, 0 dirs
/opt/X11/share/fonts/util: failed to write cache
/usr/X11R6/lib/X11/fonts: caching, new cache contents: 0 fonts, 10 dirs
/usr/X11R6/lib/X11/fonts: failed to write cache
/usr/X11R6/lib/X11/fonts/100dpi: caching, new cache contents: 398 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts/100dpi: failed to write cache
[...]
/usr/X11R6/lib/X11/fonts/encodings: caching, new cache contents: 0 fonts, 1 dirs
/usr/X11R6/lib/X11/fonts/encodings: failed to write cache
/usr/X11R6/lib/X11/fonts/encodings/large: caching, new cache contents: 0 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts/encodings/large: failed to write cache
/usr/X11R6/lib/X11/fonts/misc: caching, new cache contents: 59 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts/misc: failed to write cache
/usr/X11R6/lib/X11/fonts/util: caching, new cache contents: 0 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts/util: failed to write cache
/Users/foobar/.local/share/fonts: skipping, no such directory
/Users/foobar/.fonts: skipping, no such directory
/System/Library/Fonts: caching, new cache contents: 61 fonts, 0 dirs
/System/Library/Fonts: failed to write cache
/Library/Fonts: caching, new cache contents: 218 fonts, 0 dirs
/Library/Fonts: failed to write cache
/Users/foobar/Library/Fonts: caching, new cache contents: 0 fonts, 0 dirs
/Users/foobar/Library/Fonts: failed to write cache
/opt/X11/var/cache/fontconfig: not cleaning unwritable cache directory
/Users/foobar/.cache/fontconfig: cleaning cache directory
/Users/foobar/.fontconfig: cleaning cache directory
fc-cache: failed
real 0m54.362s
user 0m49.486s
sys 0m1.398s
So do X11 and XQuartz 2.7.11 share a common (or at least downward compatible) cache format?
What's causing XQuartz to believe the caches need rebuilding?
Is it expected that two occurrances of fc-cache run concurrently (privileged and regular startx)?
Note that above, both versions of fc-cache disagree about the number of fonts in /System/Library/Fonts and /Library/Fonts. How comes? There's no such difference about /usr/X11R6/lib/X11/fonts.
The good news is that e.g. xterm opens way before fc-cache completes.
BTW, Konsole also shows, alas without line number, 3 occurrences of
org.macosforge.xquartz.startx expr: syntax error
The Mac mini machine is almost bare bones, with very few apps installed (parts of XCode, perhaps remnants of an XQuartz from Leopard before the migration to Snow Leopard)
Thank you for your work on X11/XQuartz,
Jörg Höhle
Version: 2.12https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/16Not respecting $XDG_CACHE_DIR2022-07-01T06:16:02ZBugzilla Migration UserNot respecting $XDG_CACHE_DIR## Submitted by Alexander Puls
Assigned to **fon..@..op.org**
**[Link to original bug (#99592)](https://bugs.freedesktop.org/show_bug.cgi?id=99592)**
## Description
fontconfig is not respecting $XDG_CACHE_DIR variable, instead cac...## Submitted by Alexander Puls
Assigned to **fon..@..op.org**
**[Link to original bug (#99592)](https://bugs.freedesktop.org/show_bug.cgi?id=99592)**
## Description
fontconfig is not respecting $XDG_CACHE_DIR variable, instead cache dir seems to be hardcoded into $HOME/.cache.
Version: 2.12https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/15Relative paths in dir element are handled relative to cwd2022-07-01T06:16:02ZBugzilla Migration UserRelative paths in dir element are handled relative to cwd## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#95496)](https://bugs.freedesktop.org/show_bug.cgi?id=95496)**
## Description
They should have been done relative to current file, not the pro...## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#95496)](https://bugs.freedesktop.org/show_bug.cgi?id=95496)**
## Description
They should have been done relative to current file, not the processes cwd.
To fix this I suggest:
- We do a deprecation warning for such cases and propose a fix:
- Add a prefix="relative" that makes the relative path be relative to current file,
- Add a prefix="cwd" for relative to cwd. Might be useful for `<dir prefix="cwd">`fonts.conf`</dir>` for some usecases...https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/84fontconfig test fails2018-10-02T06:43:34ZBugzilla Migration Userfontconfig test fails## Submitted by Petr Gajdos
Assigned to **fon..@..op.org**
**[Link to original bug (#47704)](https://bugs.freedesktop.org/show_bug.cgi?id=47704)**
## Description
Test fails imho because of wrong out.expected.
fontconfig-2.9.0/tes...## Submitted by Petr Gajdos
Assigned to **fon..@..op.org**
**[Link to original bug (#47704)](https://bugs.freedesktop.org/show_bug.cgi?id=47704)**
## Description
Test fails imho because of wrong out.expected.
fontconfig-2.9.0/test[1]> for i in 4x6.pcf 8x16.pcf ; do fc-query $i; done | grep "family\|size"
Pattern has 18 elts (size 32)
family: "Misc Fixed"(s)
pixelsize: 6(f)(s)
Pattern has 18 elts (size 32)
family: "Sony Fixed"(s)
pixelsize: 16(f)(s)
fontconfig-2.9.0/test[0]> cat out.expected
Fixed:pixelsize=16
Fixed:pixelsize=6
=
Fixed:pixelsize=16
Fixed:pixelsize=6
=
Fixed:pixelsize=16
Fixed:pixelsize=6
fontconfig-2.9.0/test> cat out
Misc Fixed:pixelsize=6
Sony Fixed:pixelsize=16
=
Misc Fixed:pixelsize=6
Sony Fixed:pixelsize=16
=
Misc Fixed:pixelsize=6
Sony Fixed:pixelsize=16
Version: 2_1https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/81Add caching of PostScript names2018-10-02T06:56:38ZBugzilla Migration UserAdd caching of PostScript names## Submitted by Isaiah Beerbower
Assigned to **fon..@..op.org**
**[Link to original bug (#18095)](https://bugs.freedesktop.org/show_bug.cgi?id=18095)**
## Description
Created attachment 19703
A patch which adds the desired feature...## Submitted by Isaiah Beerbower
Assigned to **fon..@..op.org**
**[Link to original bug (#18095)](https://bugs.freedesktop.org/show_bug.cgi?id=18095)**
## Description
Created attachment 19703
A patch which adds the desired feature.
I am working on GNUstep's (http://www.gnustep.org/) font support. One
of GNUstep's goals is to implement the OpenStep specification
(http://www.gnustep.org/resources/OpenStepSpec.pdf.gz). Fontconfig is
already being used by GNUstep, however, in order to properly implement
the OpenStep standard the PostScript name should be used to uniquely
reference a font. Right now GNUstep is using the full font name,
however, it would be better if the PostScript name was cached so that
it could be used instead.
I've attached a patch (postscript_name.diff) which implements this functionality.
Related are these threads:
http://lists.freedesktop.org/archives/fontconfig/2008-October/003028.html
http://lists.freedesktop.org/archives/fontconfig/2008-June/002957.html
**Patch 19703**, "A patch which adds the desired feature.":
[postscript_name.diff](/uploads/68287e1245efb05d6fc80d61cf74573b/postscript_name.diff)
Version: 2_1https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/26Change default order of latin fonts2022-07-01T06:16:03ZBugzilla Migration UserChange default order of latin fonts## Submitted by Frederic Crozat Crozat `@fcrozat`
Assigned to **fon..@..op.org**
**[Link to original bug (#17263)](https://bugs.freedesktop.org/show_bug.cgi?id=17263)**
## Description
Created attachment 18468
tweak font order
Thi...## Submitted by Frederic Crozat Crozat `@fcrozat`
Assigned to **fon..@..op.org**
**[Link to original bug (#17263)](https://bugs.freedesktop.org/show_bug.cgi?id=17263)**
## Description
Created attachment 18468
tweak font order
This is an open topic (we've discussed it shortly with Bedhad on irc) :
-shouldn't DejaVu fonts be favored over Bitstream Vera fonts (since there has not been any vera release for a while, unlike dejavu)
- should Luxi and Nimbus be favored over Arial / Verdana / Albany AMT ?
I don't have strong opinion for the second question (for the first one, it would seem logic to favor DejaVu but I feel free to prove me wrong).
I'm attaching mandriva patch we use for this.
**Patch 18468**, "tweak font order":
[fontconfig-mdvconfig.patch](/uploads/238d33ce36267250d13d70c6d24ed864/fontconfig-mdvconfig.patch)
Version: 2.6