Re: [PATCH] Do not remove UUID file when a scanned directory is empty
"Keith Packard" <[email protected]> Mon, 29 Oct 2018 22:48:56 -0700
| Newsgroups | gmane.comp.fonts.fontconfig |
|---|---|
| Message-ID | <[email protected]> |
Akira TAGOH <[email protected]> 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. 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. -- -keith _______________________________________________ Fontconfig mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/fontconfig
signature.asc
(application/pgp-signature, 832 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAlvX8MkACgkQ2yIaaQAA ABEUVA//ePdzpyVe/ALtNIcfkg6pC0IBlgN8wr88TMAinMEcHiTdjdxSqfE0PEWT krnNNWqEtk4cleGYzFT8Zku3w/6JPgIJ1FL1vdWgkOiWOmQyGRH6ICwK83zvm2Wq hBG7utSega4beNfgjfLFVFc2EQ8qCIvSE74umK5ut9hMeFWrlxedg9OYQ9qQKLAS +hcB/llejvtGDHp1gu9aFd/7ZqJhWiarwXnbkIxYqRTRlYh/EtxfK2u1AY6+o4UK E/UkknX+wuBMPMhOgEq9fN8iIlZrgiSDTp8Ag8qNk68sX823e/ssstK7TkWeMkxo vyMxjjse5d93QPwZpQoHa2KNmholgBgWa69OQENy3mCm1xnwRUMdhsQrCnpx69Re 56oj+OsWRXoXn+S3d25nocd7V9LkEoHs1MWgrt6CVN2eDOoBLmDLaUPIA8nM1Bqg FHiVDEg2IaNbNRR2EbEtCG3OcsMWLDzGukjSoKUtHnvT5DeDOHH1B1GdjZXHhdJB e8ic3jOYKLd3GydT7wEkYYf2GVIzE/s9WA6bhw+PEmmsWT2XdMsy8xTC3LJyoZRa zs5VEyxz/yxPEEcyhSyzGLiDDjoHN7uapyn6Ck4aW3njeQpLMNTvmcUIUBlDVqZ5 rsjV79Uafx/3Fa4mHQC7r9b3A0IaRN72rJZNYLdQ5pkDZ4t8oxY= =8k44 -----END PGP SIGNATURE-----