So, I tried to figure out why my fc-list output includes the Hershey
fonts, even though 40-blacklist-fonts.conf is included and read.
First I figured out that the glob patterns in
the /etc/fonts/conf.d/40-blacklist-fonts.conf file we ship don''t have
any effect, since fontconfig does not actually apply globs
to individual fonts. The globs in <rejectfont> are only applied to
directories, and the patterns in <rejectfont> are what is applied to
the individual fonts. So I tried to change the blacklist to a series
of patterns like
<rejectfont>
<pattern>
<patelt name="family">
<string>Hershey\-Gothic\-English</string></patelt>
</pattern>
</rejectfont>
And the Hershey fonts were still there. It took me quite a while
to figure out that I need to strip the escapes out of the fc-list
output to give the patterns a chance to work. Is that escaping
really necessary ? It is certainly confusing...
Anyway, after stripping the escapes out of the patterns, the
Hershey fonts still would not vanish. I finally came to the
conclusion that something like the patch below will be necessary
to make blacklisting work again.
Matthias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blacklisting.patch
Type: text/x-patch
Size: 2452 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/fontconfig/attachments/20051020/3190e1ab/blacklisting.bin
On Fri, 2005-10-21 at 20:18 -0400, Patrick Lam wrote:> I guess caches should be invalid if the configuration is newer than the > cache. Looks like I''ll have to cook up a patch to do that, or to put > all fonts in the cache and filter later. fc-cache puts all fonts in the > cache, but this is not true of the global cache. Suggestions?The goal was to make the caches independent of the configuration so that changes in the configuration wouldn''t affect cache validity. Otherwise, we''d have a nightmare on our hands. Can we do this? -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20051021/f7ecab7d/attachment.pgp
On Fri, 2005-10-21 at 21:27 -0400, Patrick Lam wrote:> I think that I can make fontconfig load all fonts to put them in the > global cache. But maybe it''s not such a disaster to have the *global* > cache be dependent on the config files; it might beat the alternative, > which is to load all fonts into memory and then filter through > FcConfigAcceptFont afterwards on each run.Having the local cache depend on the config files would mean that we''d have to check timestamps on all of the config files to decide whether to rescan the system for new fonts. That seems bad, but the alternative of just gettin the wrong answer randomly seems *far* worse. I realize the -1 cache files were broken in this regard... -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20051021/4d16f3bf/attachment.pgp
Keith Packard wrote:> On Fri, 2005-10-21 at 21:27 -0400, Patrick Lam wrote: > > >>I think that I can make fontconfig load all fonts to put them in the >>global cache. But maybe it''s not such a disaster to have the *global* >>cache be dependent on the config files; it might beat the alternative, >>which is to load all fonts into memory and then filter through >>FcConfigAcceptFont afterwards on each run. > > Having the local cache depend on the config files would mean that we''d > have to check timestamps on all of the config files to decide whether to > rescan the system for new fonts. That seems bad, but the alternative of > just gettin the wrong answer randomly seems *far* worse.Don''t we have to read all the config files anyway? pat
Keith Packard wrote:> It doesn''t matter -- each global cache entry has a private timestamp > which is compared only against the font file timestamp. The directories > which aren''t in the per-dir cache system are *always scanned* and > compared with global cache entries.Hmm. I may have falsified that; see line 139 of fcdir.c. You used to call FcGlobalCacheScanDir, but that doesn''t exist anymore. Perhaps it should. pat
Keith Packard wrote:> On Fri, 2005-10-21 at 20:18 -0400, Patrick Lam wrote: > > >>I guess caches should be invalid if the configuration is newer than the >>cache. Looks like I''ll have to cook up a patch to do that, or to put >>all fonts in the cache and filter later. fc-cache puts all fonts in the >>cache, but this is not true of the global cache. Suggestions? > > > The goal was to make the caches independent of the configuration so that > changes in the configuration wouldn''t affect cache validity. Otherwise, > we''d have a nightmare on our hands. > > Can we do this?I think that I can make fontconfig load all fonts to put them in the global cache. But maybe it''s not such a disaster to have the *global* cache be dependent on the config files; it might beat the alternative, which is to load all fonts into memory and then filter through FcConfigAcceptFont afterwards on each run. Per-directory caches are always independent of the configuration. pat
Matthias Clasen wrote:> So, I tried to figure out why my fc-list output includes the Hershey > fonts, even though 40-blacklist-fonts.conf is included and read. > First I figured out that the glob patterns in > the /etc/fonts/conf.d/40-blacklist-fonts.conf file we ship don''t have > any effect, since fontconfig does not actually apply globs > to individual fonts. The globs in <rejectfont> are only applied to > directories, and the patterns in <rejectfont> are what is applied to > the individual fonts. So I tried to change the blacklist to a series > of patterns likeI''ve committed a patch which makes fc-list print unescaped fonts.> Anyway, after stripping the escapes out of the patterns, the > Hershey fonts still would not vanish. I finally came to the > conclusion that something like the patch below will be necessary > to make blacklisting work again.It seems to work for me without the patch... could you check again? In particular, <rejectfont> <pattern> <patelt name="family"> <string>Hershey-Gothic-English</string></patelt> </pattern> </rejectfont> on CVS HEAD (and indeed, 2.3.90, which is what was installed on a test computer) causes Hershey-Gothic-English to not show up in fc-list. pat
Patrick Lam wrote:> It seems to work for me without the patch... could you check again? In > particular, > > <rejectfont> > <pattern> > <patelt name="family"> > <string>Hershey-Gothic-English</string></patelt> > </pattern> > </rejectfont> > > on CVS HEAD (and indeed, 2.3.90, which is what was installed on a test > computer) causes Hershey-Gothic-English to not show up in fc-list.This doesn''t quite work properly: if the config blacklists Hershey-Gothic-English, then Hershey-Gothic-English won''t show up in fonts.cache-2 and so it won''t be loaded on subsequent runs. Even if it''s not blacklisted in the future. On the other hand, if Hershey-Gothic-English is in the cache and blacklisted, then it doesn''t show up in fc-list. I guess caches should be invalid if the configuration is newer than the cache. Looks like I''ll have to cook up a patch to do that, or to put all fonts in the cache and filter later. fc-cache puts all fonts in the cache, but this is not true of the global cache. Suggestions? pat
Keith Packard wrote:> You know, the timestamp of the global cache file *doesn''t matter* -- all > of the directories are scanned when you use a global cache, so any > changes in the config will be reflected in the global cache > automatically.I don''t think that''s quite true. FcDirScanConfig checks for a global cache for a directory (FcGlobalCacheReadDir), then for a per-dir cache, and then scans the directory. If FcGlobalCacheReadDir finds the scanned directory, it returns the cached data, without checking to see that the data is out of date or not. Now, FcGlobalCacheLoad does check the global cache time against the directory time: if (stat ((char *) name_buf, &dir_stat) < 0 || dir_stat.st_mtime > cache_stat.st_mtime) // skip dir but this doesn''t check for config updates. I still think we need an extra clause checking the whole cache file against the whole config file, otherwise fontconfig will be impervious to changes in the config. pat
On Sat, 2005-10-22 at 09:26 -0400, Patrick Lam wrote:> but this doesn''t check for config updates. I still think we need an > extra clause checking the whole cache file against the whole config > file, otherwise fontconfig will be impervious to changes in the config.It doesn''t matter -- each global cache entry has a private timestamp which is compared only against the font file timestamp. The directories which aren''t in the per-dir cache system are *always scanned* and compared with global cache entries. This means that any changes in the configuration will automatically get reflected in the cache file. For example -- a configuration which excluded the file ''foo.pcf'' would cause the global cache to not contain this file when generated. Each time a program was run, it would scan the directory containing ''foo.pcf'' and again skip it, leaving it out of the global cache. Now, when the configuration is changed to include ''foo.pcf'', the next application run will scan the directory containing ''foo.pcf'' and this time it *will* include it in the cache. All without caring about the configuration timestamps. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20051022/3a5f5f9c/attachment.pgp
Keith Packard wrote:> It doesn''t matter -- each global cache entry has a private timestamp > which is compared only against the font file timestamp. The directories > which aren''t in the per-dir cache system are *always scanned* and > compared with global cache entries. This means that any changes in the > configuration will automatically get reflected in the cache file.There seems to be some confusion about the behaviour of the cache. Here''s some documentation, and a question. fontconfig''s inputs are a config file and a set of fonts. It then generates FcPatterns for the fonts present and specified in the config files. To speed up the generation of FcPatterns, fontconfig generates two caches: a global cache and a per-directory cache. The per-directory cache stores serialized versions of FcPatterns for all of the fonts in a directory; when a per-directory cache is deserialized, then only fonts which are accepted by the configuration are added to the configuration''s FontSet. Since a separate program creates the per-directory caches, the overhead of loading all fonts here is not excessive. We have two choices for the global cache. Either it can contain all of the fonts in the directory cache, or it can contain only the accepted fonts. If the global cache contains only accepted fonts, we have a dependency between the global cache and the configuration, but loading the caches is much simpler (and probably faster): fontconfig just compares the directory last-modified time with the global cache last-modified time; if the directory is older than the cache, fontconfig then reads in the cached information for a directory (without further processing). On the other hand, if the global cache contains all fonts, then the invocation of fontconfig which creates or updates a global cache is responsible for loading all fonts in a directory, writing that to disk, and selecting only accepted fonts for subsequent use. The load-cache-from-disk process also would need to select accepted fonts in that case. Currently, the global cache code stores only accepted fonts, but does not record a dependency of the cache information on the configuration information. pat
You know, the timestamp of the global cache file *doesn''t matter* -- all of the directories are scanned when you use a global cache, so any changes in the config will be reflected in the global cache automatically. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20051021/97dfb9ab/attachment.pgp
Matthias Clasen wrote:> And the Hershey fonts were still there. It took me quite a while > to figure out that I need to strip the escapes out of the fc-list > output to give the patterns a chance to work. Is that escaping > really necessary ? It is certainly confusing...I think that FcNameUnparse had better escape, but fc-list shouldn''t escape. So I made FcNameUnparseEscaped which will print out font info with or without escaping. I''ll commit that this evening, if there are no objections.> Anyway, after stripping the escapes out of the patterns, the > Hershey fonts still would not vanish. I finally came to the > conclusion that something like the patch below will be necessary > to make blacklisting work again.I think that''s correct, we''ve got to filter the patterns at some point. I''ll look at that patch again this evening, but will probably commit it. pat