On Thu, 2007-01-25 at 00:07 +1100, Angus Lees wrote: > > I can do so, but the symlinking seems simpler. defoma tracks fonts by > filename, so its possible for fonts to be scattered anywhere in the > filesystem. How does the fontconfig searching/caching mechanism > scale? For example, a naive implementation would add 40+ <dir>s to > cover the fonts from tetex-extra alone. Is this ok?
I suspect tetex is 'special' in this way. The right thing to do here
would be to put /usr/share/texmf-tetex/fonts/type1 in the list and let
fontconfig scan that one directory. Would it make sense to take a survey
of existing font packages and see where they are storing fonts now?
Should we look to fix Policy so that fonts are stored
in /usr/share/fonts at some point?
So, we can either
A. Link things to /var/lib/defoma
B. Add all of the directories to a file in /etc/fonts/conf.d
C. Add /usr/share/texmf-tetex/fonts/type1 to fontconfig package
D. Do magic in defoma to pick a 'better' directory
Any preference?
> defoma's priority mechanism for resolving FontName conflicts (in
> fontconfig's case) also relies on using the symlinks to communicate
> that information to fontconfig - but I suspect noone actually cares
> about that feature so we can lose that..
I suspect the most severe cases here are where you have .ttf and .pfb
versions of the same fonts and want to use the .ttf versions.
> Aside: are the cache files for <dir> directories always written
> to /var/cache/fontconfig/ now?
Yes. fontconfig will no longer modify the font directories themselves.
> Sure, I thought any change to the font files would trigger an mtime
> check somewhere so we wouldn't need --force, but I guess you don't
> stat every file. Just replace the fc-cache line in fontconfig.defoma
> with this:
Right, fontconfig only looks at directory timestamps, so re-writing
files will not trigger the mtime checks. fc-cache could check file
timestamps, but it doesn't.
--
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
