Re: Next steps for a reproducible Fontconfig?

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


On Fri, Jan 11, 2019 at 7:06 PM Alexander Larsson
<alexander.larsson@xxxxxxxxx> wrote:
> We would have to turn that into a dynamic snippet. But that would be a
> problem for pre-existing flatpak binaries which doesn't do this.
> Could we instead have a way to modify a previously added dir element?
> Or maybe it could handle duplicate <dir> tags such that they keep the
> original order, but update the mapping? Then we can have both the
> static snippet an a dynamic one for later flatpak versions.

There was an idea in the previous discussion to have a new element to
reset <dir> and split up <dir> into a file. that may helps you to have
an own desired font directories list instead of modifying entire
fonts.conf dynamically. this can be put into /etc/fonts/conf.d. so it
can be activated no matter how apps has own modified fonts.conf as
long as it contains a line to read config files from conf.d.
This would makes easier to have a map.

> > Here's an alternative proposal:
> >
> >         Add a per 'dir' element 'salt' value, which is stirred into the
> >         path name when generating the cache key. You'd generate this
> >         randomly when the flatpak was created so that all cache keys
> >         would not collide with entries using a different (or absent)
> >         salt value.
> >
> > With this, and my path->key mapping series, we would be able to access
> > the existing cache files for external fonts (via the mapping mechanism), as
> > well as avoid collisions between internal and external font paths within
> > the cache. And we wouldn't have .uuid files (see above).
> I like this in theory. But i don't want to rewrite the entire runtime
> font config xml file (its just to fragile). I much prefer if such a
> salt could be added by just dropping a file somewhere. I.e. a
> fonts.conf snippet that tweaked the salt of a previously defined dir
> element.
> So, counter proposal:
> Flatpak generates at startup a file like this in /run/host/fontconf.xml
> <cache-as path="/usr/share/fonts">/run/host/fonts></cache-as>
> <cache-as path="/home/alex/.fonts">/run/host/user-fonts></cache-as>
> In the runtime we create at build-time a /etc/fonts/conf.d/ file:
> <salt id="randomdata">/usr/share/fonts</salt>
> # Duplicate this with static versions for old flatpak versions
> <cache-as path="/usr/share/fonts">/run/host/fonts></cache-as>
> # This will (if it exists) override the above with the live values
> <include ignore_missing="yes">/run/host/fontconf.xml</include>
> We are basically in full control of existing flatpak runtimes, so this
> could easily be added to all of them an propagated out. However, the
> new flatpak version that creates the fontconf.xml file will not reach
> distros in a while, so the above duplicates the "most likely to be
> right" value for /usr/share/fonts for older flatpak versions to pick
> up.

Fontconfig mailing list

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

  Powered by Linux