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
