[Fontconfig] Re: fc-cache sometimes looses fonts

[Patrick Lam]

James Cloos wrote:
> Going from filename to path is in the same problem space as going
> from hash to source.  With some additional info you can come up
> with plausible results, but others could also exist.

It seems that I should store just the filename, and then information on
a per-bank basis containing the prefix for filenames in that bank.  Then
when we ask about the filename of an FcPattern, we should add the
necessary prefix.  However, this introduces a strange nonuniformity into
 FcPatternGetString: if it's FC_FILE you're getting, then fontconfig is
going to rewrite it for you and append the path of the bank.  I'm not
sure that would be a good idea, but it seems better than alternative ideas.

> AFAICS, that means each process will have to store the path to each
> cache-2 file and for each font opened will have to create a string
> in malloc(2)ed vm from that pathname and the string in the cache-2
> file to pass to open(2) or mmap(2).  This will regress the vm savings
> somewhat -- especially for programs that like to show all of the
> available fonts' names rendered in said font -- but I don't see any
> real alternative.  (Though I'd love to be proved wrong. :)

I think it's one per directory; after all, all fonts in the same
directory have the same pathname!  FcPattern contains a 'bank' field
which will tell you about the directory, and then I just set up a hash
table or something which returns the pathname of that directory.  How
does that sound?

> How this issue compares with the idea of moving the cache files into a
> single dir, naming them something like .../$(hash $pathname).cache-$ver,
> is another interesting question.  There, absolute pathnames may be OK,
> provided the cache files are re-written whenever they are discovered
> to be out of date or corrupt.   (Another interesting question:  if
> the library causes each caller to write out a cache file when needed,
> what happens when 1000 apps notice the cache file is corrupt or old
> and start simultaneously writing out a replacement?)

I don't think that changes anything, since we still have an association
between the pathname and the cache file name.

pat