fonts.cache-1 files (e.g. for grepping and validation of the mmap
codepath), as per James Cloos' request.
Remove done 'TODO' comment.
Updates for development release 2.3.90.
fc-cache once per cached architecture; add some documentation to the
FcCache structure.
Make fc-cache write out fonts.cache-2 files for directories with no fonts
(i.e. only subdirectories).
returning bogus (i.e. duplicate) FcObjectPtr values. Now use negative
values for dynamic object strings and positive values for built-in and
FcNameRegisterObjectType strings. Thanks to Matthias Clasen for
pinpointing this bus!
that aren't hardcoded into fontconfig, but generated by fontconfig
clients: keep another array of user-defined objects (indexed after the
built-in objects).
Fix compilation warning (uninitialized variable).
Add comment.
data format. Also match subdirectories when consuming cache
information. Also check dates for global cache: a dir is out of date if
it is newer than the global cache; scan it manually if that's the case.
Save subdirectory names in cache files to save time. This completely
restores the original fontconfig API, BTW. Note that directories
without fonts don't get a cache file; but then how many files would it
have in that directory...
*Serialize no longer mutates original FcPatterns, it creates a new copy
in the supplied buffer. Fix thinkos in global cache freeing and in
FcCacheSkipToArch.
The global cache now uses the same mmap-based cache infrastructure as the
per-directory caches. Furthermore, the global cache is automatically
updated (if possible) whenever fontconfig is used. Rip out remnants of
the old cache infrastructure.
'object' table (strings pointed to by FcPatternElt->object and used as
keys) and loading of object table from cache file if more strings are
present in cache file than in current version of fontconfig. Hash the
object table in memory.
probably all right to use the global cache as it was previously and
just store filenames and font info, as long as no mmap cache exists in
the directory. Of course, if an mmap cache exists, use that instead.
If a directory cache does not exist or is invalid, load the fonts for just
that directory using the old codepath.
Fix premature free of the FcPatterns belonging to the FcFontSet which we
create from the mmapped files.
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.
cache. Add *Read and *Write procedures which mmap in and write out the
fontconfig data structures to disk. Currently, create cache in /tmp,
with different sections for each architecture (as returned by uname's
.machine field. Run the fc-cache binary to create a new cache file;
fontconfig then uses this cache file on subsequent runs, saving lots of
memory. Also fixes a few bugs and leaks.
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.
Patrick Lam
Keith Packard