On Mon, Nov 28, 2016 at 2:52 PM, L. A. Walsh <fonts@xxxxxxxxx> wrote:
"It happens". My distro used to(? don't think they still do?),
create symlinks to all the fonts that had spaces in them because some
software they had didn't like spaces, so they created "dups" using
underscore. More than one program has changed case of fonts at
one time or another -- only one that I *knew* that did this was one
that renamed all the font-files to their font-name given internally --
sadly it doesn't work with Unicode-filenames.
That sounds like a packaging issue. 1) why do they ship same fonts in different packages? 2) if you means the original dirs and symlinked is duplicated, why don't you allow scanning the unified one only then?
How would parallel processes working on different font-files or
on different caches be any different than if all were updated sequentially?
It seems the risk would be mostly the same.
Perhaps. but it makes things complicated.
Depending on the application, you could likely do the updates in
memory using pipes or similar, though one could also use shared-memory or
even files in /dev/shm, though those could easily overflow memory.
Right.
As for multiple processes trying to update the same cache -- happens
That's not true if you make sure running fc-cache when you added/updated/deleted a font.
That is an expected workflow to use fontconfig.
since if I run gvim as a user, and it starts updating -- it can't update
root-owned files -- and indeed, as soon as I su-to-root for something
You can update the system fonts without su. if you run fc-cache as an user, all of caches for those system fonts will be created on your home directory as needed. of course, not always. only required when the cache is outdated or missing.
--
Akira TAGOH
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/fontconfig
