Owen Taylor wrote: >> Fundamentally it's impossible to use the same mmapped structures for >> both the 32bit and 64bit architectures, so in principle there should be >> two copies of the data in the cache file. > > While I'm not going to encourage changing the file format, at this > point :-), the "fundamentally it's impossible" statement strikes me as > incorrect ... the GTK+ memmapped cache file formats, are, for example, > architecture independent. It might not, strictly speaking, be completely impossible, but it's pretty difficult to do so, since there are a lot more interwoven pointers within the fontconfig data structures than within the GTK+ data structures. > If you rely on simply dumping native structures onto disk, how do you > deal with differences in architecture and endianess for, say, cache > files in a NFS mounted home directory? Or are there copies for > every architecture in the file, not just 32/64 bit? I generate a signature of each arch, which contains the sizes of all of the relevant data structures and the arch's endianness. When fontconfig is run on a new arch, it generates caches for that arch; if you run fc-cache, then it generates per-directory caches in /var/cache/fontconfig, and if you just run a fontconfig client, it updates ~/.fonts.cache. Both the global and per-directory cache can contain arbitrary numbers of arches. pat _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig