Since fontconfig didn't have special handling for paths in static Windows
libraries, I've created a patch which should fix this.
Basically it does this:
fccfg.c:
If fontconfig_path was uninitialised it tries to get the directory the exe is
in and uses a fonts/ dir inside that.
fcxml.c:
In case the fonts.conf lists a <dir>CUSTOMFONTDIR</dir>, it searches for a
fonts/ directory where the exe is located.
Fix a couple of longstanding problems with fontconfig on Windows that
manifest themselves especially in GIMP. The root cause to the problems is in
Microsoft's incredibly stupid stat() implementation. Basically, stat()
returns wrong timestamp fields for files on NTFS filesystems on machines
that use automatic DST switching.
See for instance http://bugzilla.gnome.org/show_bug.cgi?id=154968 and
http://www.codeproject.com/datetime/dstbugs.asp
As fccache.c now looks at more fields in the stat struct I fill in them all.
I noticed that fstat() is used only on a fd just after opening it, so on
Win32 I just call my stat() replacement before opening instead...
Implementing a good replacement for fstat() would be harder because the code
in fccache.c wants to compare inode numbers. There are no (readily
accessible) inode numbers on Win32, so I fake it with the hash of the full
file name, in the case as it is on disk. And fstat() doesn't know the full
file name, so it would be rather hard to come up with a inode number to
identify the file.
The patch also adds similar handling for the cache directory as for the fonts
directory: If a cachedir element in fonts.conf contains the magic string
"WINDOWSTEMPDIR_FONTCONFIG_CACHE" it is replaced at runtime with a path under
the machine's (or user's) temp folder as returned by GetTempPath(). I don't
want to hardcode any pathnames in a fonts.conf intended to be distributed to
end-users, most of which who wouldn't know how to edit it anyway. And
requiring an installer to edit it gets complicated.
If ~/.fonts.conf contains:
<edit mode="assign_replace" name="spacing">
<int>mono</int>
</edit>
fontconfig crashes:
mfabian@magellan:~$ fc-match sans
Fontconfig error: "~/.fonts.conf", line 46: "mono": not a valid
integer
セグメンテーション違反です (core dumped)
mfabian@magellan:~$
Of course the above is nonsense, “mono” is no valid integer indeed.
But I think nevertheless fontconfig should not crash in that case.
The problem was caused by partially truncated expression trees caused by
parse errors -- typechecking these walked the tree without verifying the
integrity of the structure. Of course, the whole tree will be discarded
shortly after being loaded as it contained an error.
Missing NULL font check before attempting to edit scanned pattern.
Also, <match target="scan"> rules are now checked to ensure all
edited variables are in the predefined set; otherwise, the resulting
cache files will not be stable.
Using a simple shell script that processes the public headers, two header
files are constructed that map public symbols to hidden internal aliases
avoiding the assocated PLT entry for referring to a public symbol.
A few mistakes in the FcPrivate/FcPublic annotations were also discovered
through this process
The Delicious family includes one named Delicious Heavy, a bold variant
which is unfortunately marked as having normal weight. Because the family
name is 'Delicious', fontconfig accidentally selects this font instead of
the normal weight variant. The fix here rewrites the scanned data by running
the scanned pattern through a new substitution sequence tagged with
<match target=scan>; a sample for the Delicious family is included to
demonstrate how it works (and fix Delicious at the same time).
Also added was a new match predicate -- the 'decorative' predicate which is
automatically detected in fonts by searching style names for key decorative
phrases like SmallCaps, Shadow, Embosed and Antiqua. Suggestions for
additional decorative key words are welcome. This should have little effect
on font matching except when two fonts share the same characteristics except
for this value.
Validate cache contents and skip broken caches, looking down cache path for
valid ones.
Every time a directory is scanned, it will be written to a cache file if
possible, so fc-cache doesn't need to re-write the cache file. This makes
detecting when the cache was generated a bit tricky, so we guess that if the
cache wasn't valid before running and is valid afterwards, the cache file
was written.
Also, allow empty charsets to be serialized with null leaves/numbers.
Eliminate a leak in FcEdit by switching to FcObject sooner.
Call FcFini from fc-match to make valgrind happy.
Replace all of the bank/id pairs with simple offsets, recode several
data structures to always use offsets inside the library to avoid
conditional paths. Exposed data structures use pointers to hold offsets,
setting the low bit to distinguish between offset and pointer.
Use offset-based data structures for lang charset encodings; eliminates
separate data structure format for that file.
Much testing will be needed; offsets are likely not detected everywhere in
the library yet.
Use open instead of fopen (requested by Phil Race for Sun).
src/fccache.c (FcDirCacheWrite);
Fix GCC4 warning and Makefile brokenness for /var/cache/fontconfig dir.
and distribute bytes for each directory from a single malloc for that
directory. Store pointers as differences between the data pointed to
and the pointer's address (s_off = s - v). Don't serialize data
structures that never actually get serialized. Separate strings used
for keys from strings used for values (in FcPatternElt and FcValue,
respectively). Bump FC_CACHE_VERSION to 2.
ids can be positive (for static strings) or negative (for dynamic
strings). Static strings belong to a single buffer, while dynamic
strings are independently allocated.
This patch allows the fundamental fontconfig data structures to be
serialized. I've converted everything from FcPattern down to be able to
use *Ptr objects, which can be either static or dynamic (using a union
which either contains a pointer or an index) and replaced storage of
pointers in the heap with the appropriate *Ptr object. I then changed
all writes of pointers to the heap with a *CreateDynamic call, which
creates a dynamic Ptr object pointing to the same object as before.
This way, the fundamental fontconfig semantics should be unchanged; I
did not have to change external signatures this way, although I did
change some internal signatures. When given a *Ptr object, just run *U
to get back to a normal pointer; it gives the right answer regardless
of whether we're using static or dynamic storage.
I've also implemented a Fc*Serialize call. Calling FcFontSetSerialize
converts the dynamic FcFontSets contained in the config object to
static FcFontSets and also converts its dependencies (e.g. everything
you'd need to write to disk) to static objects. Note that you have to
call Fc*PrepareSerialize first; this call will count the number of
objects that actually needs to be allocated, so that we can avoid
realloc. The Fc*Serialize calls then check the static pointers for
nullness, and allocate the buffers if necessary. I've tested the
execution of fc-list and fc-match after Fc*Serialize and they appear to
work the same way.
memoize strings and share a single copy for all uses. Note that this could
be improved further by using statically allocated blocks and gluing
multiple strings together, but I'm basically lazy. In my environment
with 800 font files, I get a savings of about 90KB.