On Mon, Nov 12, 2018 at 6:14 PM Nicolas Mailhot
<nicolas.mailhot@xxxxxxxxx> wrote:
>
> > Its not that hard to define the mapping of the host /usr/share/fonts
> > into the container. However, this is not enough, because you will then
> > use "/usr/share/fonts" as the cache key for this directory, which
> > conflicts with the /usr/share/fonts in the container.
>
> So what? That just changes directory scanning to
>
> if (not hit(key(entry), maincache)) and remapped(entry) and
> hit(key(preremap(entry)), mappedcache) then
> copy(data(key(preremap(entry)), mappedcache), maincache)
> else
> computedata(entry, maincache)
> end
>
> in quick and dirty handwaiving pseudocode
>
> As a bonus you do not poison the main cache with host cache data relate
> to things not mapped in the container.
>
> Or am I missing something totally obvious?
I'm not sure exactly what maincache and mappedcache is. Fontconfig has
one single cache, spread over multiple directories, with no connection
between individual font dirs and the cache dirs.
If a directory is called (or is mapped from) /usr/share/fonts/foo,
then we'll be looking for a file called md5("/usr/share/fonts/foo")
in all the cache dirs, in the order specified in the config files
(first one wins).
i.e. if we have a situation with the two dirs:
<dir>/usr/share/fonts</dir>
<dir map="/usr/share/fonts">/run/host/fonts</usr>
Then when scanning for /run/host/fonts we will look for
md5("/usr/share/fonts"), and when scanning for /usr/share/fonts we
will *also* look for md5("/usr/share/fonts").
We could possibly tie each dir to a cache dir in some way. That was
actually something I considered. But if so, that has to be part of the
new design, because that is not how it works now.
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/fontconfig
