Re: [PATCH] Do not remove UUID file when a scanned directory is empty

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 30, 2018 at 2:48 PM Keith Packard <keithp@xxxxxxxxxx> wrote:
>
> Akira TAGOH <akira@xxxxxxxxx> writes:
>
> > Not rare today. this has been made to improve flatpaks startup time
> > because regenerating fontconfig caches always happened.
>
> I'd like to find a solution which doesn't involve writing files into the
> font directories themselves, but I'm having trouble thinking of how that
> might work without involving changes in the flatpaks themselves. All we
> really need is some way to compute the right cache file name given the
> path found inside the flatpak.
>
> Is the .fonts.conf file for the flatpak computed dynamically? Can we
> adjust how that is built? What if that file contained an association
> between the paths it uses and the paths used outside? We could then
> construct the external path from the internal path and use that to
> generate the right cache file name.

Well, the essential problem is there in the cache structure itself.
the cache contains the hardcoded font path to identify its targeted
font directory. this is used to check the updates etc though,
re-scanning always happens because those font paths aren't available
in flatpaks. this can't be addressed by having own fonts.conf. if we
are going to find a solution, we need to get rid of it from cache and
find another way out to make dirs and caches reletionship.

>
> Would we need more than one mapping per <dir> element in the font
> configuration?
>
> Alternatively, a flat-pak using system could place a magic file in each
> top-level font directory for fontconfig to use for this mapping. As that
> would simply contain the name of the directory in the external
> namespace, it would be easy to generate with a shell script even. At
> least we wouldn't be creating and destroying these files each time
> fc-cache runs, as we wouldn't need them in each new directory, only at
> the top of each font tree.

Hmm, perhaps. or I suppose flatpak should have a sort of mapping table
of directories between host and container. so they could tell them to
fontconfig through API if we provide it and fontconfig can assigns
dirs against it.

>
> --
> -keith



-- 
Akira TAGOH
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/fontconfig




[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux