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.
Old cache file versions, or corrupted cache files should be removed when
cleaning cache directories with fc-cache. This only affects filenames which
match the fontconfig cache file format, so other files will be left alone.
Some mingw versions have broken X_OK checking; instead of trying to work
around this in a system-depedent manner, simply don't bother checking for
X_OK along with W_OK as such cases are expected to be mistakes, and not
sensible access control.
fc-cache would say 'skipping: %d fonts, %d dirs' or 'caching: %d fonts, %d
dirs', which could easily mislead the user. Add 'existing cache is valid' or
'new cache contents' to these messages to explain what it is doing.
This call was followed by a call to stat(2) which provided the necessary
information. This call to access(2) was necessary when cache files were
stored in the font directory as that would check for write permission
correctly.
Use filenames to clean cache files for current architecture only. This is
sufficient as cache files live in their own directory where filenames are
under fontconfig control.
Looks like the last directory in the project which didn't use $(WARN_CFLAGS)
for some reason. Adding that found the usual collection of char * vs FcChar8
* issues (why, oh why is FcChar8 not just char...)
Borrowing header stuff written for cairo, fontconfig now exposes in the
shared library only the symbols which are included in the public header
files. All private symbols are hidden using suitable compiler directives.
A few new public functions were required for the fontconfig utility programs
(fc-cat and fc-cache) so those were added, bumping the .so minor version number
in the process.
Instead of making filename canonicalization occur in multiple places, it
occurs only in FcStrAddFilename now, as all filenames pass through that
function at one point.
Instead of passing directory information around in separate variables,
collect it all in an FcCache structure. Numerous internal and tool
interfaces changed as a result of this.
Charsets are now pre-frozen before being serialized. This causes them to
share across multiple fonts in the same cache.
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.
With the removal of the in-directory cache files, and the addition of
per-user cache directories, there is no longer any reason to preserve the
giant global cache file. Eliminating of this unifies the cache structure
and simplifies the overall caching strategies greatly.
Normalized directory names offer protection against looped directory trees
but cost enormous numbers of system calls (stat per file in the hierarchy).
Also, cache file directory name contents are validated each time the
directory is modified, don't re-validate every time the cache file is loaded
with an access and stat call.
Make fontconfig compile under MinGW:
1) remove unneeded #includes;
2) make use of mmap and sysconf conditional;
3) replace rand_r by srand/rand if needed;
4) use chsize instead of ftruncate; and
5) update libtool exports file
current config in fc-cache.c. Fix treatment of cache directory as read
from cache file; don't use string equality to determine if we have the
right file, use inode equality.
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.
helps make fontconfig FHS-compliant, but requires that all caches get
rebuilt.
Also, autogen.sh now needs the additional parameter
--localstatedir=/var.
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).
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...